Ultimately, for a software developer choosing the best tool stack for a set of requirements, past backward compatibility history is generally not an important critera. You can say, "You can't blame toolset XYZ, they had to make trade offs for backwards compatibility!" and that may be accurate from the perspective of the people working on that toolset, but today's software developer should pick the best tool for today, not based on how well the implementation team handled various trade offs in the past.
Only problem is that in lots of cases you have to work with existing code bases you can't just ditch, and in some cases this means using an older language or using a language which retains backwards compatibility. And usually the latter is the convenient option, in that context.