As someone just rolling out an internal XML service, it's mainly because JSON hasn't caught on with the corporate developers. Try to bring it up in a conference call without having half of the parties misunderstand it as "A guy named Jason will do the data feed part of the project for us".
He, hehe, hehehe. I've been on that conference call.
XML is probably supported on more platforms, and certainly has better support for transforming into other formats (there are some analogs to XSLT for JSON but they're nowhere near as ubiquitous as XSLT processors
"supported on more platforms" is relatively bogus when the libraries are open source. And I'm sure that all currently in use languages and platforms, even enterprise ones, have JSON parsers. I'd venture to say that one needs the ability to transform XML into other formats using tools like XSLT because XML is often so hard to work with, and I don't think this limitation is necessarily a serious problem with JSON, since the format is so simple and there are fewer serious ambiguities as to how things should be serialized in JSON, not having the concept of child nodes vs attributes (as one example).
Not sure how it applies to this specific problem, but comparing JSON and XML in a general case is like comparing a Prius and a M1 Abrams. Obvious examples: XML has multiple ways of defining validation (in a way even your text editor will understand). XPath. XSLT.
As thwarted points out, the entourage of XThings that follow XML around only exist to prop up the inherently awkward XML itself, whereas JSON, being more or less a straightforward serialization format for the data structures we all know and love, has no need for these things. To refine your analogy, I would say XML is to JSON as an M1 Abrams is to a sensible foreign policy of non-interference.