I have lately been asserting that so much of computing interfaces is essentially materialized views into a database. Whether that database is relational or not really doesn't matter. Aggregation rollups and flat data entry are easy to see in that world with transformation from the flat data store that users directly write to into somewhat normalized backend systems that are all constantly running jobs to materialize the views that the rest of the systems use.
To that end, I heavily stress that there is no single "data as data" view of any data in the system. It is all a transformation of some sort from somewhere.
This is not to say that I disagree with your general statement. I would stress that the same "data" can have multiple representations in the "data" world. (This is not uncommon for outside of programming, either. Easy to consider that 1/3 is .33333... or 3.3...e-1, etc. Canonical formats for any data item are things you have to work to build, they do not come for free.)
At the end of the day, it is data. It might get read out of 3 different underlying systems, enriched by some kind of computation (dynamic or computed attributes vs ones that are actually persisted to a db, etc) but it is data.
If you can think in data, as you say the underlying mechanisms for storing and retrieving that are less important. They are when it comes to performance and persistence guarantees, but if you abstract things correctly, that becomes easier.
Recently I saw a post here that clean architecture was dead. This is hilarious to me and not true. If you are writing a low-level script, sure you can avoid that and optimize ... but for larger systems (ie, anything that is outside of a single process), clean+hexagonal is the way to go.
To that end, I heavily stress that there is no single "data as data" view of any data in the system. It is all a transformation of some sort from somewhere.
This is not to say that I disagree with your general statement. I would stress that the same "data" can have multiple representations in the "data" world. (This is not uncommon for outside of programming, either. Easy to consider that 1/3 is .33333... or 3.3...e-1, etc. Canonical formats for any data item are things you have to work to build, they do not come for free.)