I think you have it exactly right, but I'd like to expand on the example.

Imagine an organization that has a sizeable group in charge solely of the database -- including replication across many servers, rational backup schemes, auditing and authorizing changes, optimizing queries and maintaining performance, etc. -- and then a wide variety of other groups which both develop applications as well as users using a variety of SQL reporting tools. The entire exercise can get exceedingly complicated and it can be pretty clear how triggers and stored procedures can be immensely useful for the DB group to maintain control.

From a one database to one application relationship these tools don't seem to make as much sense.

Mark