The problem with XHTML is that the "abort on parse failure" behaviour simplifies a computer science problem at the expense of creating a business problem; now if you have an error somewhere in your content generation pipeline it means that the site goes down. That's a pretty difficult tradeoff given that most CMS are absoutely not designed in a way that ensures well formed markup.

Back in the dim and distant past when XHTML was a fashionable term to throw around, Evan Goer did a study of whether sites claiming to serve XHTML were actually doing so. The results were not pretty [1]. Some people took the results as a challenge and tried to ensure they were sending valid XHTML with the correct mime type so that browsers would catch fire in the case of a parsing failure. In almost every case it turned out to be possible to get their sites to break with user generated content (e.g. searchng for XML-invalid characters which were then echoed back onto the page).

So I contend we ran the XHTML experiment pretty thoroughly 15 years ago, and it turns out that it doesn't really work. Once you accept that parsing errors being fatal isn't viable for publishing, you have to have some kind of error recovery system. The one in HTML isn't ideal since it's basically just the codification of many years of improvisation and reverse engineering. Maybe something like XML5 [2] would be better. But figuring out how to move the world in that direction is an unsolved problem. Meanwhile HTML Just Works for most of the people most of the time.

[1] https://goer.org/Journal/2003/04/the_xhtml_100.html [2] https://github.com/annevk/xml5