Right you are as a developer / programmer. However, VBA has a huge part to play (factually it does, as well as should) in more complex models developed by excel users rather than “real” programmers. There is very little OOP required for 99% of VBA that is still massively useful.

Incidentally, the Binomial Tree model I built in VBA uses OOP and a linked tree data structure. It’s not the fastest thing on the planet, but the guys who work with me can all hack their way through the basic ideas.

I’d almost suggest that there are several tiers of the use of VBA and .NET in conjunction with Excel:

Hacked recorded macros to repeat tasks. Useful but dangerous, ugly and risk-prone. Still makes Excel more useful than without this, and requires no programming knowledge at all
Coded macros with little structure and manually defined ranges. Possibly the most dangerous, and the one area I don’t think should be promoted at all.
Well-coded, but basic User defined functions. This is a great space. No risk of deleting cells and ranges or breaking things, but provides additional functionality and encapsulation of more complex tasks. I find this works well when providing a complex model to a client, so the code is hidden in the background and the use of the model is still non-VBA excel based.
Well coded VBA code, possibly including forms and a UI. Can be useful, but starts to suggest the need for a more structured programming approach.
Non-VBA, .NET or DLL approach. More advanced, more structured, faster, but much more limited in terms of the number of people who can do this. Often, it becomes clear that the model probably shouldn’t be excel-based in the first place!

So there really is a range of applications on a continuum of skill-requirements. You and I have already had discussions around hammers and nails for that matter!

Furthermore, long running macros should actually be written as a decent COM component that exposes its interface with asynchronous calls, so that the Excel UI isn’t locked up. That should enable the user to continue working on another workbook while the COM component does it stuff with the initial workbook.