Same reason as SOAP/WSDL: there's good money in consulting so it would be stupid to do something that to simple, people might be able to solve their own problems.

Honestly I get that there an advantage in respect to tooling and this might ease integration into existing system, but I can't help feel that this is introducing an extra level of complexity that you would only find acceptable if you at IBM customer level scale.

The ability to introduce at least some type safety seems nice though.

Because there are already tool chains to handle XML with features not (widely) available for JSON, for example validation (XSD) and transformation (XSLT).

This is so true. Xsd is so useful.

To use existing XML 1.0 tools on data that comes in as JSON.

It may be somewhat problematic that it doesn't actually support all JSON, because the characters that are permitted (even with escapes) in XML 1.0 text do not include all characters that can appear in JSON values, so if you use it on legal JSON that isn't constrained to be XML 1.0 compatible, it will do something wrong (the docs aren't clear on whether it will fail or just drop the offending characters), so the only place that it seems safe to use is in a constrained internal environment where you control "JSON" to mean "JSON using XML-1.0-safe characters".

> the characters that are permitted (even with escapes) in XML 1.0 text do not include all characters that can appear in JSON values

Do you have an example of this? I'm curious what character you could have in JSON that you couldn't represent in XML using the '&#' syntax.

Edit: To answer my own question, backspace is an example of such a character.  is not valid XML.

This. I'm not claiming it is a good idea... But, DataPower is a highly optimized data processing network appliance for XML. It provides transform speeds with minimal latency, etc. So, to extend its capabilities to a new popular data format (JSON), they transform JSON to XML.

ENTERPRISE READY!