Are Stored Procedures bad?

I have always thought that you should use stored procedures when ever
possible. But, after reading this:
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
My world view is shackled.
Are stored procedures good or bad?application programmers and database programmers have different goals.
database people need to have the bigger picture in mind. Sure, our data
is ONLY manipulated by one front end. Except for reporting. and OLAP
in 3 years.
And, oh, by the way, we need a NEW front end for part of the data. and
we want to start importing/exporting the data to different sources.
Oh, did I mention the business rules changed again?
My experience is that I need to make it EASY for the app programmers to
use my sprocs.
OTOH, I have to also keep in mind I need to maintain data integrity,
whatever that means for that week. So, in general I control DML into
stored procedures.
If an app programmer wants to create his own select statements, I
usually let them. If a programmer wants to do his own inserts/deletes,
we schedule the security changes for sometime after hell has a frost
depth of 53 inches.
If they go over my head, then I get the app owner to sign in ink they
no longer need the dba to maintain data integrity, and give real world
examples of duplicate customers, or duplicate orders, or deleting
orders and all their history out of the system.
from there the argument digresses down to "dba's can use foreign keys"
blah blah blah, and I digress down to "inclusionary vs exclusionary"
and I repeat my offer to make the tools for the programmer, and the
programmer won't take ownership of data integrity, and the the schedule
gets pushed back even further.
stored procedurs offer a common interface for the data, and some
business rules for a variety of front end apps. they can also offer
significant performance advantages because the dba can make changes to
take advantage fo data layout without changing the various front end
applications.