I don't ever like to hear speculation about whether the DBA or programmer needs to fix something. My answer to this debate is simple: If you claim it, then show me the metrics. Let's also review the SQL code that is executing. It isn't all that hard to insert the ability to log all SQL queries at their start and end as well as all important units of code that can be switched on an off at the app level. That gives an immediate picture of whether to refactor app code, refactor the SQL code, optimize the database, or restructure how the data is being stored and accessed.
Regarding the debate about using stored procs and Entity Framework: Every programmer should understand SQL and manually review all generating SQL queries. It isn't hard to put in logging that grabs generated queries when certain thresholds are crossed. It's up to the CIO/CTO to put in a good framework and pattern that is documented, enforced and effective at logging these kinds of things for review and monitoring. That is a management and policy issue. The leadership needs to make sure that there are appropriate resources invested continuously to handle this. If they don't, then development and forward momentum becomes harder and slower as time goes on.
That said SQL is archaic. If you step back from what you are used to, it is ridiculous that we need to optimize databases and manually decide on where to put data (on what disk should this table or portion of data live). The SQL instance is already seeing the requests coming in and the frequency. It should be aware enough of itself to make decisions about how to manage the physical hardware resources and organization of underlying data for itself.
For flat queries, EF works great with stored procs and I use them where appropriate. But what am I supposed to do when I have large amounts of data that require server side paging with user defined, multi-column sorting with dynamic search terms? And even worse, what am I supposed to do when those results map to relational objects that are also returned? It's a shame SQL hasn't addressed the issues that LINQ expressions a EF have. SQL has no means to easily tell a stored procedure about dynamic sorting with server side paging and optionally included sub results (essentially dynamic joins). LINQ and EF handle this really well. The thing that tells me that SQL needs a rethink is to review the generated SQL that is our LINQ and EF create to achieve this. It's chunky because SQL gives no better option to query code. The SQL code "advances" made in 20 years have not been anywhere near the level of advances that have been seen in other coding languages.
Clouds and hybrid solutions that are coming out for data storage and retrieval are definitely advancing. Our organization now has a policy of writing all applications to be totally agnostic of the underlying data store. We can use SQL, NoSQL, local databases, WCF, SOAP, rest API's, could services or hybrid data stores to get and save our data. The data storage and retrieval code can be totally changed out using IOC and dependency injection without ever changing the core application code, UI or business logic. The point of this is that we are "detaching" ourselves from direct reliance on in-house SQL databases.