The idea is to abstract the business logic off to the stored procedures, so you'll be unlikely to be doing just a simple select.

Indeed, keeping everything the side of the database more often speeds things up in my experience. You're not moving data over the wire so all processing is happening locally. For example, doing anything involving iterating over a set of rows is likely to be a lot faster if you keep everything on the database side. It's also common to have more CPU cycles to play with on the database server too.

So I guess my experience is the opposite of yours :-)

This isn't to say I always think stored procedures are a good idea.

They are highly database dependant for example. If you're dealing with multiple databases, or if its possible you'll want to switch platforms, stored procedures are probably a bad idea.

Also, if you're only developing a single application then many of the safety advantages in isolating the business logic in the database disappear. An API in one language is just as good as an API in another. In this case it can make sense to keep everything in a single language so you don't have to find a PL/SQL (or whatever) coder for the team.