At the same time, back-compatibility is frightfully horrific. I really feel for the x86 engineers, for one thing.
And it's no protection against a true disruption - I was going to say "such as webapps and mobile", yet Java is strong on both (server-side and smart-phone). So it must be doing something right. I think it's that its depth of libraries (and tools and coders) means that you can fulfill any particular need more quickly than any other way - which is the application of programming languages. The depth of libraries is directly supported by back-compatibility (the old ones still work).
And, in this sense, it just keeps getting better and better.
Reading that pile of documentation and interviewing the hordes that tend to the application are much more work than it would take to write a more modern version of whatever that does with 1000 lines of Perl (or Ruby, or Lisp, or Python, or Erlang, or Haskell).
It's not as much as Java did something right, but more like we did too much around it.
Disclaimer: I am currently struggling with a web application that's little more than a CRUD, but done with what I call "framework bingo" on top of a complicated network of servers, with dedicated Mule feeding Elastic Search servers where a simple CRUD (even the one that comes free with Django apps) feeding a static file system would offer better throughput and easier troubleshooting than the huge pile we see there.
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.