I used to do all of my business logic coding that way, also - in Transact-SQL stored procedures. It's technically a "violation" of the old three-tier client server architecture, but it was blazing fast, immune to user error (and power-user manipulation), and the company was not going to be moving away from SQL Server for the foreseeable future, anyway.
I have no doubt new college graduates would have been baffled and horrified - but my business users loved me. :)
It is very reusable which I like. We have a vast store of SQL code lying around that we can adapt. Best of all, our enterprise system interface is written in Oracle Forms, which is all PL/SQL. We can mine procedures and functions all day.
My problem is dealing with cursors passed to Groovy. They were fast when we started but kept modding the queries which slowed them down. In hindsight, I should have used XML. Live and learn. Never pass cursors.
Hmmm - a portion of our business is rescuing businesses that have all their logic written in sprocs.
After several hundred no one can manage them. The same functionality gets repeatedly created, and the spaghetti multiplies.
Eventually the logic breaks, the app shuts down, the company shuts down, and we get a panic call promising us whatever amount of money we want. :-)
With a strict set of protocols and meticulous documentation stored procedures can be managed. But I advise clients to not use them except for special cases that might have critical speed or security requirements. Both of which have mostly gone away over the last few years.