It seems that communities that mainly use programming languages for reasons of "getting stuff done" value backwards compatibility the most; they are the ones who would rather not have to spend the time "upgrading" things that used to work perfectly fine, and would rather use that time to do something more useful and related to their ultimate goals. Personally I think backwards compatibility is getting less attention than it deserves, and that software should evolve slowly and gradually and not suddenly make huge leaps, because all these breaking changes start to look like they're just creating unnecessary, wasteful work. Imagine if things like mains plugs changed every few months, with appliancemakers all adopting the newest backwards-incompatible version. In some ways software is easier to change than hardware, but at the same time we must remember that effort needs to be expended to perform these changes as well, effort that could be used in other ways, and often there is a lot of interconnectedness in the systems we are trying to change.

"Imagine if [...] plugs changed every few months, with appliancemakers all adopting the newest backwards-incompatible version"

like apple?

Similar to Innovators/Visionaries vs Pragmatists (http://www.chasminstitute.com/METHODOLOGY/TechnologyAdoption...)

Furthermore, with scientific computing, it's important that code you publish in a journal (fossilizing it) can still be at least near-usable to others over time horizons of years to decades.

That's definitely one important aspect. And even stuff not formally fossilized often becomes de-facto fossilized due to the way funding for development works. Things are often very bursty: a large library or piece of software may be written over a period of 2-5 years of concentrated effort either by a PhD student, or by programmers/research-scientists/post-docs hired on an NSF/DARPA/EU-funded research project. But then the PhD student graduates, or the project ends (and therefore its funding for programmers), and the software goes into much lower-staffing maintenance mode. In that mode there aren't resources available for anything but minor fixes. There are some very high-profile projects that are an exception to that pattern, because they're seen as important enough that they manage to string together continuous development for years or decades, either through a series of PhD students or a series of grants. But lots are more or less write-and-then-maintain. Despite being lightly maintained, if the initial work was solid and produced a reasonably "complete" output, it might still be useful to other researchers for years into the future, if it doesn't bitrot. Some of the R packages are a good example: plenty of stuff hasn't been touched in 10+ years but is still in daily use.

Differences in userbases are definitely part of it.e.g. Ruby is very often used in the whole devops space - where constant forward-change is usual, because of the mindset of "never being done".

Constant change is a thing that doesn't get enough mindshare as well. Not training your team at handling change is probably as bad as not having programmers care about backwards compatibility.

To be quite clear: I think it is very beautiful to have 2 languages in the same space, evolving into different community directions.