Hi,

Data pages are still recommended in this scenario for several reasons:

1. Data vitrualization - the best practice is to separate the physical data model (report) from the logical data model (data page) so that your applications are more easily able to react to change.

2. Parameterization - data pages can be parameterized and called from many places with their parameters. This is not true of reports.

3. Reuse - you may only require a single data source (report) for your data page now, but if this changes in the future, you're much better setup to account for that change so your data page can be reused in multiple different contexts. Additionally, if you need to swap the data source out with a different report or different source type, you only have to do this on the data page vs. everywhere your report is referenced.

4. Deletion - read-only data pages can be automatically deleted by the system after non-use. Requestor level pages can be deleted automatically when there are no longer any referring threads.

5. Scoping - data pages can be requestor or node-level, thereby increasing resource sharing and improving performance. 

6. Tooling - All of the tooling related to data in the product is centered on data types and data pages (e.g. data explorer and data designer), which makes using data pages far easier.

7. Future optimizations - There will be future performance optimizations at the data page layer. 

That said, you should really only be using refresh per interaction if you absolutely have to. It's better to use alternative refresh strategies when possible.

Kalim