1. The user experience sucked
2. The developer experience sucked
What XML needed was good quality editors, validators, programing language libraries, and, above all, documentation for people who aren't on the standards committees. What we got instead were people on standards committees and enterprise architecture groups trying to show off what deep thinkers they were, with the assumed inevitability meaning that boring details like actually implementing something could be left as an exercise for the student.
Namespaces are a great example: this is a core language feature, a really powerful tool, and you'll hit the laziest possible implementations as soon as you try to use them. You start with something reasonable:
<foo xmlns="http://example.org" xmlns:custom="http://example.org/somethingelse">
<bar>
<custom:baaz>…</custom:baaz>
</bar>
</foo>
That's a nice way of separating ownership, looks great. Then you start trying to parse it, write XSLT or XPath, etc. and find that you can almost never write “custom:baaz" the way it shows up in the document, or often even /foo/bar, because the tools expect you to work with the internal representation (“{http://example.org}foo/{http://example.org}bar/{http://examp...) and so you might see error messages saying "<custom:baaz> not found” in a document which has that exact string, validation errors from tools which use different libraries than what was used to author the document, or, better, silent data loss because you didn't notice that some selectors weren't matching. Many programming language interfaces will require you to repeat those declarations everywhere because, of course, it would have been far too much to expect that a query against element <bar> inherit the namespace declaration from its parent.Again, this is a key feature which has been around since 1999 and decades later you can still still find people writing things like //*[name()='baaz'] or stripping namespaces entirely before rage-quitting XML. Everything harder is worse: basic usage requires internalizing 6 different ponderous specs on different release cycles, figuring out which of the examples had never been tested and which worked when the author wrote them but are now unsupported by the particular tools you're dealing with, etc. Bonus points for realizing that you had a never-valid document which was just punted down the line by multiple enterprise systems which have had increasingly lenient validation added over the years by developers who were told it was too expensive to fix the previous system.
I'm not sure XML can be saved at this point but I'd start by modernizing libxml2 since half the open source world is stuck in stasis when that stopped getting new features in the early 2000s, and then focusing on non-expert usage. A full GUI editor would be a lot of work but simply having high-quality command-line tools and implementations for common programming languages would go a long way towards not giving people excuses to switch.