Don, thanks for helping clarify some of my thoughts. I am a bit of an OO lover for sure, but it is 100% true that you can do OO just as badly as any other programming technique (I have sure seen that in action...).
I just find that real world data and process structures are neatly mapped by either OO or finite state machines. If you have an environment that has first or second class support for both of these, then your job in designing a good system is well supported.
In your defence software example, I would put money on the fact that the Ada developers were much more highly skilled than the (more commodity) C++ developers (although that is a complete guess). Give the Ada developers smalltalk and see what happens ;)
You are right about perl's internals. The regex engine is so complex that noone has successfully made it deal with mixed utf8 strings (unlike the rest of perl which does),
but that's just for your interest...
My thought about maintenance might be better explained. I was more thinking of when you want to slightly change the behaviour of a package in a client site, but in a way that's not suitable to be committed to cvs. If we had an OO design, you could, say, subclass the forums to allow files to be attached to messages (yes it's a lame example). The subclass would survive minor version upgrades to the core forum package. Currently, we need to hack the forum code (or duplicate a bunch of it) and upgrades then require manual merging.
I'm loving this discussion!
