Any Argument for Extremely Lengthy Stored Procedures?

I've recently come across the code-base and DB for a VOIP application. It's like a murder scene.

The app has countless (many hundreds of) MySQL stored procedures that go up to 900 lines long ! It was written in 2006. The stored procedures hold most of the business logic (practically all of it) and the code is very much unreadable, poorly structured.

One of the longer SPs that sifts through a lot of data across 10 tables (max. 5 GB) is called almost 15 times a second depending on the traffic.

I was talking to the senior engineer who managed the project back then. He, to my surprise, defended the application's design very ferociously arguing that a data-intensive, read-heavy application demands such long stored procedures because of performance considerations. He was willing to do the same today, even with everything that is available now.

3 questions:

• Does any one with a database background think there's a better way? Like using in-memory stores for frequently-accessed data ? Or caching?

• Should good design still be important, and the business logic be shifted to the code?

• What kind of a situation would justify this design?

Would seriously appreciate some well-thought opinions. Thank you.