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.)

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.

But of course, the middle layer that applications talk to need not be the database. A simple RPC server between the apps and the database makes maintaining the system significantly easier. Your procedures are "normal code" that you already have a toolchain in place for dealing with. (Testing, libraries, version control, etc.)

The environment is richer, which means the middle tier can handle caching, sharding, replication, auditing, and anything else that you might need to add. And, you can add these things incrementally, without touching the apps that speak to this server.

IMHO, stored procedures are a quick hack that are barely viable for even the simplest tasks. Many people seem to disagree, but I doubt they have ever considered any other way.

(A notable example of this system is Flickr. Their internal apps, like the public web interface, use the Flickr API to do their work. In this case, the web app that powers the API is the "middle layer"/"RPC server". I think this worked out pretty well for them, and it made it easy to expose their database to third parties.)

1) Sproc 2) Scattered around the app haphazardly

The only apps I've seen use the BLL-as-an-sproc trick were written by people without any experience writing scalable code at a real company.