I find this editorial interesting because over a decade ago I the development team I was working on had this exact discussion.

I was a developer at that time and I was pushing everything to stored procedures. The limitation we had the time though was that I was unable to do queries via stored procedures because the database I was working with and the application deveopment tool would not allow results to be returned and consumed. This was also help lead us into the discussion of using views.

The number one reason for the failure of using stored procedures was that we where a RAD/JAD, Rapid Application Develpoment / Joint Applicaiton Development, shop. Because of this we constantly making changes midstream and between knowledge of the development staff of being able to write procedures and the turn arround time of getting changes to the stored procedur applied to the database. Slowly the code shifted back to the application tier.

Fast forward to today and the new champion is Entity Framework. It has become the choice to create the abstraction from code to database tier.

For the most part abstration is a good thing. I really don't want to have to remember how to write the code to add an item to a list array. I just want to be able to call $list_items += "New Item" and be done with it. Just like a developer doesn't want to rewrite the code everytime to loop through results and add result paging or to do work around all the plumbing to do a simple insert and update of a record.