LOL!! Why not put the business processes in the standards too, then you won't need any code!
The point is, no-one running any apps against your database has a choice but to respect the business processes if it's all implemented in stored procs. You are protected from malice, from incompetence, from simple human error, and your auditors and regulators and shareholders are happy. Maybe no-one cares if it's only a website.
Also I am hilariously amused that you don't think stored procedures can live in version control like any other source code.
I'll note I'm not talking from experience here, I'm just speculating and hoping for somebody with more practical experience in the matter (or better insight) to enlighten me.
Most of the time, it's because the organization thinks in terms of SQL and relational tables. There are better ways to do business logic.
We do it that way so the business logic exists and is enforced in one place...Only the most trivial applications can afford to put all their business logic in the middle tier.
There are much better ways of enforcing business logic and controlling it all in one place, which would be compatible with configuration management/source control and much more convenient for most programming teams.
(Namely: just publish the business logic as a library and have standards that dictate its use. These can be enforced using automated scripts and a little process. You are also not restricted to the middle tier, though I'd still say it's a good idea.)