We use both in-line and sproc-based code.  Just finished a .NET utility to selectively copy tables from one db to another -- often on different servers in different environments (DEV, SIT, PAT, PROD etc). doing it with sprocs would mean a lot of dynamic SQL and the procs installed on every participating server.  Since the program is run ad-hoc, that is not a viable approach.  But I admit this is a special case.

Others mentioned EF and ORMs in general.  Did anyone say LINQ to SQL?  Love it or loathe it, it does make development easy for .net gurus who are SQL noobs.  Of course it can use stored procedures too, but that can be less convenient and does require extra knowledge or coordination with SQL specialists.  Then you have double-promotions: one for the app another for the db.  Sometimes with different deployment teams and approval cycles.

I think someone mentioned SSIS (and lets include SSRS, SSAS).  Those can use procs too, of course, but it is less convenient than a simple source component to destination data flow