There's no shame in code that is simply "good enough"

The rule of the thumb: If an extension point is used by only a single extension, get rid of it. It won't fit the next extension anyway so the work needed to maintain it in the meantime is a waste of time.

I disagree with your point that the verbosity of Java is the reason for over-engineering. The refactoring capabilities of modern-day IDEs help immensely with reducing the amount of work one has to do to make syntactic changes over the whole codebase. So the argument that developers tend to over-engineer when coding in Java to avoid any pains that may arise because of its verbosity doesn't hold, IMO.

I think that the over-engineering happens simply because it's a pain to do serious refactoring when working on large enterprise software in general, never mind what language it's written in. The sad truth of our profession is that the customer requirements may change quickly and drastically, requiring us to rewrite large portions of our code, and very often we find ourselves thinking "If I only engineered it that way instead of this way, I wouldn't have so much trouble right now". This is why we strive to create the most robust, flexible solution that will be able to handle any future customer requirement. So we basically turn our code into a framework that, we hope, will allow us to respond to change quickly. Unfortunately, we can never predict everything that the users might want, so this whole approach falls down like a house of cards when a user requirement comes in and we need to change a large portion of the code. I believe this is true for a sufficiently large app written in any language, Haskell included.

Good points; we were building an in-house solution for an Investment management wing in a bank.

To give some context on the trade reference I referred to, it was an internal tracking within the STP system used solely for tracking state and for communication between IT and the business. It was a simple date + numeric value used in our STP system for users to use in our Struts web and C# front end to check trade state through the STP flow and communicate with us if issues arose.

We did have lots of interfaces where it made sense and relied highly on object composition to represent financial concepts more richly and for inject-ability via Spring and Unit testing (makes writing tests easier when you mock things out). Asset types, security identifiers, etc, were represented correctly from an OO perspective and were a part of the xsd layer/interface between us and the trading systems. To us these were read-only values we just passed through for STP.

You are right about interfaces and unit testing but this is one case I highlighted of many where I think the lead was going over board. The internal trade reference was the same for 8 years and still the same to this day (which gives it another 3 years since I left for a total of 11 years). It never had more than one concrete class. It is no big deal on its own, but when combined with the other interfaces that only have one concrete class, it just bloats the system for no good reason.

Design and architecture is good for the reasons you have mentioned and more but it can go over board as is the case here IMO. There were other instances of that in our code base but that would take an entire blog post to cover some of the atrocities this engineer created because of his forecasting ability.

"Since I don't have any experience with it, what do you think is the reason that it's not used very often for building large enterprise applications (or maybe it is, and I just don't know about them)?"

Well, I don't know if it's even clear why other languages are used for enterprise software?

I don't think that their technical or whatever superiority was the main reason. Sometimes it seems that everything that is needed is to push it with a lot of marketing into the mainstream and then just let it go.

At some point there're more libaries for a language, most people use that language, universities are teaching it, so that's then the main reason to use a language.

Java might been there, pushed into mainstream, at the right time, with the right features, which made it less complex and less error prone (garbage collection, no memory pointers) to use, compared to C/C++.

But perhaps there's something about "object orientation", how it's implemented in Java, which makes it for people easier to grasp, if I read all the hate about these strange scheme/lisp courses in universities, but perhaps they're just already used to much to other languages.

On Haskell, at the beginning it looks very strange, especially compared to languages like C/C++, Java or C#, but I think that most of the felt strangness is a matter of habit, because most of the mainstream langugages aren't that different.

I don't think that learning Haskell was that much harder for me than learning to program in C++ or Java. Sometimes people seem to forget the challenges they had, when they learned programming for the first time.