Stored procedures are easily tested.

But one has to first embrace the idea of not having a static "test database". One has to view the database as something that is created as part of test setup. That approach is consistent with continuous delivery principles. If one does that, then testing a stored procedure is as simple as reading the resulting data in the database. No other test streams are affected because you created a test database as part of your isolated test setup, in on on-demand isolated test env.

Pushing to prod is simple: you simply have a script that deploys the stored procedure to production databases.

Stored procedures also can be - should be -stored in source code repos just like any other code.

SQL injection is actually safer with stored procedures, because the inputs and outputs to the procedure are clear: you can verify that those are handled correctly, instead of having SQL scattered around throughout application code.

The biggest benefit of stored procedures is that you can encapsulate actions that need to be transactionally consistent. That's a very important thing for those "juniors" to learn about.