According to Moore (Chasm guy), new technologies tend to get standardized on by big organizations. Adopting it in the first place was hard enough, and they want to put off doing it again for as long as possible. The infrastructure and dependencies (those huge piles) are a big part of why it's hard to change. Some are important and necessary dependencies that are expensive to change no matter what. I think this is characteristic of the enterprise.
Back-compatibility facilitates this postponement of change.
I daren't be an apologist for that webapp (esp since I don't know anything about it and I agree with you anyway), but my inner contrarian pipes up with Joel's essay on rewrites
(http://www.joelonsoftware.com/articles/fog0000000069.html). Though it sounds like there isn't even a grain of truth with respect to the architectural decision.
I believe this specific application can be rewritten in a week or so. If we factor in all the resources that had been dedicated to making small changes and the disproportionate amount of effort dedicated to make sure those small changes didn't break everything else, I'd go with a rewrite even if we kept the whole damn thing in Java, just with a saner architecture.