XML is used in countless standards. You can't just not use it if you interact with the outside world. Every XML feature is still in the many XML libraries because someone has a need for it, even things like external entities.

Maybe you don't need libxml2 specifically (good luck finding an alternative to parse XML in C and other such languages though), but "I don't like the complex side of XML so let's pretend it doesn't exist" doesn't solve the problem most people pick libxml2 for. It's the de-facto standard because it supports everything you could possibly need.

It's common for both the producer of XML and the consumer of XML for any given application to be using a dramatically smaller subset of the standard. Well-engineered software is intentional about this and documents those limitations. Under these conditions it's perfectly valid to use a library that only supports this subset.

Furthermore, those subsets have natural "fault lines", influenced by the burden:utility ratio. This makes consumers and producers naturally coordinate on a subset. It's not like another commenter here said about everyone needing different features.

My argument is therefore that there is value in having different libraries for different subsets - with the smallest subset being much simpler than libxml2.

Exactly. For example if you need to integrate SAML, you have to support a significant subset of several XML specs. It may be possible to write a SAML-only library that supports less, but it's not clear it would be any simpler.

You shouldn't be down voted, its just the truth no matter how unfortunate.