Yet Another DBA (8/31/2016)
I try and get the developers to see the sprocs as an interface much like a RESTful or api. So easy to setup testing or mocks against and they don't need to worry about the implementation if they don't want to.The benefits even for simple crud is that the Business Logic can be preserved away from the Data Logic. So If I need to add audits or archiving data to slower disk or more unusual performance tweaks then I can without the risk of asking the developers to change any of the business logic.
There are of course those who seem to believe that orms are the only way to do things and then quote facebook or google as the example of it must be okay if they use. We are of course not the size of google/facebook and are not leading edge.
I don't tar all developers with this brush but I do see a certain amount of myopic lazy coders who seem to thing that it is just C# code and sql is bad and too difficult to learn. As a senior developer pointed out that without the data what is the point of the application.
I think this is because database developer type people are seldom included in early design/requirement phases and databases end up as seen as just some place to put data. This means the actual potential for database integration as a legitimate part of project development is either ignored or not designed/implemented properly if it is(EAV data would never exist otherwise).
Stored procedures certainly end up as a victim of that particularly when it comes to things SQL is good at like bulk data manipulations or interacting with objects that might not be part of whatever ORM they are using.