I think at this point issues like these are pretty much baked in already. The vast majority of applications don't use stored procedures, because they are a. extremely vendor specific b. written imperatively, rather than declaratively, in vendor specific languages that let's face it are about as user friendly as REXX (Google it, kids) which make them very difficult to be expressive with c. are not very straightforward to keep versioned in source control (of course they can be versioned, but the pipeline from db environment -> source control typically has to be pretty custom, plus you have to get your DBA to use it) d. introduce all kinds of novel problems in integrating with application-level constructs such as database drivers, SQL builders, and dare I say ORMs, where while these are all potentially solvable areas (yes including ORMs), are not being solved, because the folks who swear by stored procedures pretty much despise all those other things.
So in some ways the way the stored procedure community is so opposed to application level constructs is kind of what keeps the community isolated, and in some cases, renders what might be useful technologies as completely unused (where I am referring to MySQL stored procedures, which...exist! But I wouldn't dare ever try to use them because who wants to be first, really).