It's not so much a technical issue as a mindset issue - having several different teams maintaining the same code because they've all decided cooperating is too much work makes little technical sense really.
In theory this is right, in practice this can be wrong.
Java runtimes have been problematic because getting good performance and reliability out of java requires good code generation, threads, locking and garbage collection. Writing a demanding application is a matter of negotating a style of using threads and memory that works. Small changes to the semantics that still result in 'correct' behavior (matches the spec) can lead to an app that seizes up periodically, ringing your pager at 2 am.
There is something to say for staying on the bleeding edge... Particularly if your level of support from the product developers is good enough that you can get hard problems fixed rapidly. If, on the other hand, you're getting your support from your average vendor (such as a certain market leading Linux distribution) you'll need to take a very large number if you have a hard problem, and in the interest of keeping your line-of-business system up, you'll stick with what works.
