Stored Proc biz-logic architecture was a big thing in the 2000s. MSSQL with its T-SQL were very common (and its polymorphic AND multi-table return types, could make for some very interesting control flows sometimes). There was a lot of bitterness about it back in the late 00's and early 10's, and it drove a lot of ORM adoption.

I worked for a shop in the late 00's and early 10's that had Very Big Database Servers doing several hundred million transactions per second (100+ core, multiple RAMSan, etc. type bare metal servers), and stored procs were the way the go. They were basically the interface layer to the data, and it allowed us to keep the interface (or even version it) but change how access happened behind the scenes, like splitting a table into partitions, or replacing a bad performing query with a differently structured one that did better, which made it a non-concern for the frontend code that was responsible for getting data and formatting it, and didn't really care about _how_ that data was retrieved.

I have been pushing a pet idea that we should leverage our RDBMSes as platforms more than we do. Pretty frequently the model layer in MVCs end up with some functionality that would be much more robust inside the database. Validation ends up being done (at least) twice, query results end up being quite distant from objects, transactions which should be one are split, etc. Problems that could be mitigated with user defined procedures in the database.

I think it might be the current state of version control tooling that's in the way here. It can be a tricky and often fairly manual process to sync database changes (even just running the migrate command) when releases are tied to git repos.

That's not to say git repos aren't wonderful, but I see underutilization of database functionality as a subtle downside.

I don't have to imagine. I was paid for a while to work on Oracle Application Express apps.

There were things that were neat. But a lot of it came from the head-scratch-inducing genus of genius.