Stored Procedures have been around for a long time, so it's very easy to put some business logic closer to your database without resorting to the level of integration suggested by the post.
yes but in my experience even though they exist, many applications are written in an outside environment, in order to take advantage of software engineering facilities that are not available "in the DB". This competes with the idea of merging the app into the DB and is why the split is common place.
There might be performance improvements and better abstractions from moving what is traditionally known as "application code" into a place where it has better, more direct, access to the data.
I'm not saying that we should be throwing out SQL and starting over, but if there are massive gains to be had by letting the database do MORE (or redefining what the database actually is, maybe "merging" it with the application code so that this new "thing" has knowledge of both how the data is stored as well as how it will be processed), why not explore those?
Honestly I'm being vague because I have no real idea what I'm talking about here, but if you look at the past, you see this in many other areas. First the FPU joined the CPU, then the GPU joined the CPU, then phones happened and you get the SOC where everything is in the "CPU".