It boils down to how many of us are able to code logic in stored procedures vs how many of us are able to do it in backend language X.
The tools to edit, version control, run tests and deploy are also important but are a consequence of the number of developers that will use them.
If every single backend developer would be a DBA and a SQL master we'd write applications in SQL and we'd have great tools to do it. But we're lucky if in a given project there is one single developer that understands SQL well enough, not at DBA levels.
That said, is it architecturally better to write application logic in stored procedures inside the database or in a different language outside the database? An interesting question. I see good points for both choices but given the world we're in the pragmatical one is the latter.
Leaving it too generic brings your backend application to give up on performance, by refusing to optimize the data layer.
Working towards a better Database optimization leads to huge speedups in the application itself.
A well done store procedure beats easily any ORM construct (especially JPA in Java).
And what about dealing with error handling? Tighting the error handling to model makes it easier to unit test it extensively and enables DRY on your codebase, since you don't have to repeat the error checking in all the places your model is used.
I keep my SQL statements as close to standard as possible, so a change in Database Engine (say MySQL-->Postgres) results in a simple step.
The unit tests can be performed as a bunch of SQL statements passed as input to the database client and verify that it works as expected. This level (the unit test) can also be done with any programming language of choice, to make the task easier.
The tools to edit, version control, run tests and deploy are also important but are a consequence of the number of developers that will use them.
If every single backend developer would be a DBA and a SQL master we'd write applications in SQL and we'd have great tools to do it. But we're lucky if in a given project there is one single developer that understands SQL well enough, not at DBA levels.
That said, is it architecturally better to write application logic in stored procedures inside the database or in a different language outside the database? An interesting question. I see good points for both choices but given the world we're in the pragmatical one is the latter.