I agree though that XML is overkill for describing payloads in most RPC scenarios. XML is for describing semistructured data rather than co-inductive data structures (arrays, records, etc.). JSON shines here precisely because it doesn't need a schema to be useful.
However, once you have a need to communicate your API to others, or to develop in a large project/waterfall model, schemaless doesn't cut it. JSON Schema is doing it wrong IMHO. I think that since JSON is basically the object literal syntax of JavaScript, an RPC mechanism could use a JavaScript subset as IDL, in the style of "Logic Programs as Types of Logic Programs" ([1]).
Note that WSDL can describe REST-like and other HTTP-based protocols, not just SOAP.
[1]: http://www.informatik.uni-ulm.de/pm/fileadmin/pm/home/fruehw...
A few years ago I had to use some public API offered by the Norwegian government through a private-sector partner [1]. Looks like they're still completely SOAP/WSDL-based even today. (At the time I just needed to use a single endpoint, so I ended up just doing everything as plain XML, instead of generating an RPC client from WSDL; so much easier. Ugh, I'm glad I don't work for a company that is heavily invested in that crap.)
I can't imagine anyone sane would do a greenfield project today using any of it.
[1] http://ws.infotorg.no/