Or at least they really shouldn't be.
Spreadsheets are all about sheets, rows and columns. Every piece of your spreadsheet logic is going to be engrained in this model of cell references - at best by name, but mostly by row and column. Rows and columns are the domain model for spreadsheets.
I discussed in my last post how important it is to be programming in the right domain model, or your code will be substantially more complex and more difficult to maintain. I call this mixing domains.
The domain model for business applications must be specific to the field of the business. For a loan business, the business application should be talking about loans, customers, payments, and drawdowns.These entities make up the domain model for your business application.
If you have business applications created as spreadsheets, then you're losing out on a lot. Firstly I'm sure you would have noticed how unmaintainable it soon becomes. Secondly you're creating a gap between business specialists who understand the business, and the convoluted logic that only technical people can understand in your spreadsheet. This gap is expensive for a business as it directly impacts the TCO and speed at which business solutions are developed and extended.
The better solution is to develop the business application in domain-centric platforms, such as using a workflow product (or domain specific language), or constructing a domain in a general purpose language such as C# or VB. Unfortunately there are not many business application development platforms that are quite as 'RAD' as Excel may feel (although this feeling is somewhat deceptive given the mess you end up creating).
The same can also be said of Stored Procedures. The domain model here is tables, rows and fields -- database management. SQL is a language that was created to describe relational queries between tables, it was not meant for creating business logic. Doing so, again, is mixing domains and just ends up in more complex and unmaintainable code.
This really backs my argument that what we really need are more domain specific languages. Programming languages that can be developed or reviewed by business experts and that more closely resemble the actual requirements for the project.