Cita: Usar procedimientos almacenados no está del todo bueno porque te queda parte de la lógica en la base de datos.
Usar stored procedures (y lo digo con total conocimiento de causa), es la mejor forma de resolver procesos donde sólo debe intervenir la base de datos, como pueden ser cadenas ABM en los que el overhead de la red es pasible de generar inconsistencias, o en procesos que deben ser completamente atómicos, como ser la cadena de procesos de una factura y/o pago que se emite.
La base de datos guarda datos, pero si escuchaste a los profesores de BBDD en clase debes recordar que ademas
procesa datos para devolver información, y en ese contexto, los SP son total y absolutamente necesarios.
Como ya comenté, trabajo para una empresa donde es un requisito de seguridad informática que no se hagan peticiones a la base que no sean por SP.
¿Es el sql-injection la única razón?
No. Hay otra muy interesante: Puedes hacer funcionar todo un sistema de altísima complejidad con usuarios que lo único que pueden hacer en la base es LOGIN y EXECUTE ROUTINE.
En cuanto a lo de que "la logica debe estar toda en la aplicación" es cierto... pero lo que debe estar allí es la lógica del negocio,
no la lógica de datos, que son dos cosas totalmente diferentes.
La aplicación tiene la lógica de negocio, eso sin duda, pero trasportar a ella la construcción de las consultas, porque esa no es lógica de aplicación, y generas uno de los peores defectos que existen: exceso de acoplamiento con la base de datos.
Si migras la lógica de los SP a la aplicación esclavizas al sistema con un modelo de datos, donde cada ajuste requerirá de inmensas cantidades de programación adicional. Mientras que cambiar proceso en base, no la afectará en nada.
En resumen: No hay que confundir la lógica del negocio, dominio de la aplicación, con la lógica de BBDD.