Don't get me wrong
In a 50'000+ PHP code lines, maybe 5'000+ SQL query lines and 40'000+ C# code lines, my colleague and me used only 10 stored procedures for operating with data and 50 stored procedures for reports.
We agreed that using stored procedures for everything is really bad, but we also agreed that there are some cases when we could put a small part of the business logic (if it can be really considered as a business logic) into SPs.
While I think you will agree that SPs for reports are OK, the other SPs manage the integrity of the data for statistical purposes - i.e. instead of deleting a record and related ones we delete some of the relation records and mark the others as deleted (i.e. indeed it's an UPDATE operation). That's because we can't really delete a data because it absence will reflect onto the reports. We could do it even with triggers, but that would put "business logic" into every table declaration.
So, I'm not a SP-user, simply I didn't like some of the statements in this thread.
I do agree with most of the things you (repeatedly

) mentioned as a whole, but I don't agree with some parts of them.
I'll keep using foreign key constraints, unique constraints and everything else provided by the DB engine in order to keep the integrity of the DB data, so even a buggy application will not going to ruin its integrity
