Baptiste Mathus, I'm not sure you are helping the XML1.1-argument when you remind people that XML 1.1 was published in 2004. Any software standard that is not well-supported after more than a decade is not likely to suddenly gain widespread acceptance.
But, as I mentioned before, it looks like Jenkins isn't really doing XML 1.1, anyway. The code is just emitting the header, then doing business-as-usual for the body. That's weird, but not a deal breaker. No one is going to switch away from a great technology like Jenkins just because they have to do a little text-replacing when using one of the APIs.
I'm not sure what mailing list you think I should join. But, I can give a quick explanation of what we are using the XML for.
My company tracks changes to configurations of most of our off-the-shelf and open-source software (as well as some hardware) in something we call the "recovery system". This recovery system is a little like an automated backup, except that it can be used to easily view changes made to confirmations. The system is often the first place people go where there is a mysterious service disruption since it aggregates all changes together into a single timeline.
The code our "recovery system" uses to extract Jenkins' would be more-or-less agnostic to XML-type (since it largely doesn't care about the format of the configuration it is backing up) except that it gets a lists of things to track by inspecting the output of other XML APIs. (such as jankins.hostname/api/xml). At time of writing this, I'm not 100% sure which API calls were failing to parse, since the person on my team who fixed this did so in a very-general way and it's unlikely all of them failed (given my example doesn't have a header at all). But, maybe I can provide more details after locating the mailing-list.