yes you're right. but that one instance of doing so, but not the only way. I dislike it too since they put an emphasis solely on the app and not on the data.
what I had in my was just idle thoughts about providing disentangled primitives that could be used to build other things on.
for example
the primary key for accessing a file/object could be (computer_id?, storage_id or partition_id , object_id/inode)
+ ways to define different kind of indexes based on you use cases.
instead of just making apps into silos you can have the things builts on top of these primitives be typed structured data objects + API/interface.
have an Object explorer and programs can declare they they are able to display or manipulate custom data Type X.
you can then have GUI be composable the same way the pipe operator work in the cli.
you can define a regular filesystem on top of these primitives, a relational database, a tag system, or something new all together.
if you don't want folders you would ca to deal with them.
the work on fushia OS seem to explore something along these lines (BlobFs + MinFs + Components). (https://fuchsia.dev/fuchsia-src/concepts/components/v2/intro...)
Pharo/SmallTalk seem to also explore the ideas akin to this. (https://pharo.org/)
to be fair the current state of affairs is similar enough with file extensions + mime info if you squint hard enough and pretend that app and systems folders files don't exist but it's held with pinky promises.