Everything is a "security bug" in the right (wrong?) context, I suppose.
It's true that once upon a time, libxml was a critical path for a lot of applications. Those days are over. Protocols like SOAP are almost dead and there's not really a whole lot of new networking applications using XML in any sort of manor.
The context where these issues could be security bugs is an ever-vanishing usecase.
Now, find a similar bug in zlib or zstd and we could talk about it being an actual security bug.
I'm aware of plenty of usage of SOAP, but only between companies that have contractual relationships with each other and who could easily sue each other if one of them tried to exploit a security bug.
That greatly mitigates the risk of a security bug being exploited, especially something like a DOS attack that is easily noticed.
Quite the opposite. NETCONF is XML https://en.wikipedia.org/wiki/NETCONF and all modern ISP/Datacenter routers/switches have it underneath and most of the time as a primary automation/orchestration protocol.
I'm not saying XML is unused.
I'm saying that the specific space where it's use can cause security problems from things like a DDOS are rare.
A legacy backend system that consumes XML docs isn't at risk of a malicious attacker injecting DDOS docs.
When XML is used for data interchange, it's typically only in circumstances where trusted parties are swapping XML docs. Where it's not typically being used is the open Internet. You aren't going to find many new rest endpoints emitting or consuming XML.
And the reason it's being used is primarily legacy. The format and parser are static. Swapping them out would be disruptive and gives few benefits.
That's what it means for something to increasingly become irrelevant. When new use slows or stops and development is primarily on legacy.
That being said, I don't think that libxml2 has support for the dark fever dream that is XMLDSig, which SAML depends on.