There is actually a reasonable arguement for the stored procedure one. It means you can have different permissions for tables as you do for stored procedures so your application doesn't have permission to directly query your passwords. The benefit there is if an attacker gains access to your application and/or the DB authentication credentials they cannot then export users passwords or other sensitive information.
Seems more efficient to me to use column-based permissions in this case, and create stored procedures for the queries you need to interact with the "sensitive" columns.
That of course does increase (dba) administration overhead, but it seems on it's face simpler and far more "programmer efficient" than storing every single query as a stored procedure.
It's a difficult thing to generalise but if you have a pretty large or complex application and DBA (or several) then it does sometimes pay to have your DBAs write the SQL because it's a different enough paradigm from normal backend development that not all backend developers are skilled at writing perfomant SQL. However few applications are that complex, not all businesses can afford a dedicated DBA team, and there are clearly a lot of very talented developers who can turn their hand to multiple different stacks. So it's a difficult thing to generalise.
