This is how I do relational databases in 2019. My database is a self contained module more akin to an rpc api than a database. My code has virtually no database logic in it at all. I don't know but it feels like functional databases could be a thing. We should call Martin Fowler and ask.
SQL is already a pretty functional language. It's a nice low statefulness, transactional layer around a very stateful core of data. Fully exploiting this gives you many benefits. This is the reason noSQL databases tend to be subpar.
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.
A few years ago I wrote an accounting software using that approach. The C++ code was calling predefined set of stored procedures and most logic (especially constraints) was in db. Fixing bugs not related to GUI was easy and, in most cases, not visible to end users. We also had a request to let an external software to insert some data into certain tables. I just created the procedure for this particular case and guys from another company just integrated their software without any problems.
Returning JSON to a client is relatively recent. The standard for web apps was to get data from the db and generate HTML on the server. A JSON layer would be a useless overhead.
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.
Returning JSON might be recent, but multi-tier apps where one tier talks to the data storage and applies business logic served up to a presentation tier dates back to long before the web. The rise of the web caused a lot of developers without any history with multi-tier applications to push "flatter" apps, that is true, but in terms of software development in general it's not new.
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.
