This is something I've thought about a lot over the years, not in small part because the connection pooling work that I mentioned above was during my first few years out of college where I worked at MongoDB on some of their database client libraries. I know MongoDB gets a lot of criticism on these parts of the internet (which at least in terms of technical opinions is in my opinion a mix of stuff that's warranted, stuff that's a bit more nuanced than internet arguments might make it seem like, and some stuff that's mostly just holdovers from the very early days that hasn't applied to any version of the database people have used in the past decade), but one of the things I always found interesting about it is how it changes the experience from what you describe to one where the bulk of the work is figuring out the best way to model the data (where you have to care about things like "how 'many' is this 'one to many' relation" and "when I access this data, is there any other data I'd almost always expect to need to access at the same time?"), and if you've done that right, the queries themselves end up being a lot more straightforward to come up with (either single operations like "find this" or a pipeline of transformations starting from "find this" and then "do this to the output of the last stage", compared to the "inside out" way you sometimes have to wrap up subqueries in SQL with outer queries).

It's a reasonable take that changing the entire way that the database modeled everything under the hood is an overkill solution to the specific problem you mention compared to something like LINQ that can work on top of existing databases, but I can't help but wonder if there's a bit of inertia in how willing people are to challenge their usual ways of thinking about how data modeling might be possible to improve because a lot of people don't get exposed very much to anything other than the raw, string-like handling that you mention (which is annoying but at least SQL injections are a well-known thing nowadays and tend to be possible to avoid) or a full-blown ORM (which quite often ends up either being wildly inefficient or needing to drop back down into the raw SQL in some places to avoid the performance bottlenecks, which kinda defeats the entire point). A startup I worked at a few years ago actually had what I thought was a pretty clever solution to this problem, with their product generating OpenAPI/GraphQL APIs for a given database by inspecting the schema (with optional parameters to get back EXPLAIN data in the responses to verify that the query was what you wanted, and the ability to define custom routes with raw queries that were checked into shared version control with the schema migrations if you weren't happy with the query it generated as a way to properly separate concerns as an improvement over the traditional ORM workflow), but despite the idea seeming quite enticing to me from a technical standpoint, I guess it didn't show enough traction to be able to survive.