Rik Hemsley wrote a little post on "Stored Procedures vrs Dynamic/Embedded SQL". Neat comparison!
Personally I like to think of the database as its own black box. In itself there should be rules and logic necessary to keep data integrity. That's where I lean on StoredProcs heavily.
There are a lot of design patterns out there that pull the business logic out of the database and into some sort of business tier. That's fine but I believe you can efficiently split that logic into something that maps closely to the database especially when transactions are needed.
I do my best to avoid 'monolithic transactions'. That's where the developer opens a connection to the database, begins a transaction, and then has their way with the database. It's a common strategy but very inflexible. I believe small transactions kept at the stored proc level works better. Then if needed you can nest them in larger transactions at the "business logic" layer.