Also, huge are the performance benefits of not always pulling data across multiple layers of cache, across the network, back into multiple layers of cash of another computer to be processed by some script running far away from the original data. Processing and aggregating as much as you can as you are retrieving the data is often multiple orders of magnitude faster and more efficient than sending everything elsewhere to be processed.
This is how datomic ions work, i think.
Furthermore about everybody knows how to use an ORM. Not many people can write store procedures. Maybe the question is why is that so. I heard "I know [language], I don't know SQL, so I write queries in [language] " so many times even from people I would have expected to have a much broader knowledge. (That also applies to networking technology, they know HTTP and nothing more.)
By the way the code doesn't address authentication and authorization, those go in the layer between the client and the database.
Even in terms of web dev, well over a decade ago I worked on a system where we had a middleware layer that consisted of a service that handled the business logic and talked to the database. This middleware layer took requests from a web frontend layer did most of the presentation and served up in various formats. The web frontend never talked directly to the databases. It gave us flexibility in how we sharded things, and in applying different extents of access control (e.g. we could put different frontend services in front of the middleware) as well as use it to enforce constraints that were impractical to express in the database. How important that is certainly depends on the database you use.
It wasn't a new thing then either - I took inspiration for that system from much older systems.