"[I]t already broke backwards compatibility several times". There's your answer. I've got three decades worth of style files, personal macros, and workflow invested in the way I use LaTeX, numbering in the thousands of lines. In some communities, especially academia and most especially amongst mathematicians and engineers, that is a typical investment. Nothing that might require me to start overhauling that is going to get a moment's consideration until LaTeX stops working for me, and even then I'm probably going to try and maintain a bespoke TeX distro before I'd try to replace it. New and casual users of LaTeX should probably consider these alternatives (I've even considered moving over to LuaTeX because it would allow more automation, but I'd need a pretty longish period of reimplementation that I don't see becoming available soon.) But anyone who wants to move that community of long-time users, organizations and publications is going to need to address the problem of a significant user base that have been using effectively the same software for literally (and according to my students, unbelievably) decades.

There's an analogous situation (or a continuation of this same situation, given the overlap in user base) for those who've invested decades in building a personal set of Emacs configuration files. Again, I've got thousands of lines of *.el files (many of them devoted to my idiosyncratic use of LaTeX) in my Emacs configuration. Of projects looking to replace the aged Elisp engine and create a modern implementation aren't going to get much consideration if it would mean replacing that (literally decades of) work in a different language. That's why I continue to be interested in Guile Emacs---less because of Guile (although I have no issues replacing Elisp with a modern Scheme), but because they've always made it clear that an ability to re-use Elisp configuration files was a primary design goal.