Agreed! That was also one of the original goals of WinFS in Longhorn, but I wonder if it was just too early. The original problem with WinFS is that it was too slow, but that was before SSDs and several Moore doublings ago.
Possibly too early, or possibly too ambitious. Looking at the Wikipedia article[0], it feels like it was definitely too ambitious. The design seems to have everything that you'd expect out of a full-blown relational database.
BeOS feels more like a document database - no defined schema, just attributes attached to your files.
that's because it was a full blown relational database - it literally shipped with a desktop variant of SQL server (MSDE) and the WinFS bits were implemented in .NET on top of that.
I recall installing the WinFS beta 1 release and suddenly the winfs-related background processes were eating up 150MB+ of RAM at a minimum, even with no stores created or files indexed - when machines back in 2005 had 512MB of memory that's actually a lot for what is supposed to be a background service.
Windows XP back then only needed 128MB of ram to run. they made a mistake in not building it on top of something akin to sqlite - hell they could've implemented maybe 70% of what they shipped in beta 1 with just sqlite alone.
I think AS/400 does a similar thing, but I don't know a lot about it. PICK OS was also similar.
[0] https://birdhouse.org/beos/byte/24-scripting_the_bfs/