Earlier quoted context omitted.
I'm not sure what you think your JSON parser is doing.
Come on. Any one of us could write a JSON parser in a page of code. An XML parser is significantly more work due to the overcomplexness of XML. Both to write, and for the CPU to run. And it's larger. In fact I'm struggling to think of something XML has that is good. (And please no one respond with "it's extensible" or I may explode). An XML parser has to track open tag names, with JSON it doesn't matter. XML has all…
However, that statement should be understood through the filter of the fact that I've only seen one thing that uses XML namespaces properly, and that's XHTML. Everything else I've seen gets it wrong, and that includes most things trying to deal with XHTML....
You also get a "free" and modestly powerful validation system, a serialization format that has seriously thought through encoding issues and has answer for them (JSON does too, but a lot of other fly-by-night stuff doesn't), a fairly powerful format for tagged text (JSON-tagged text is a hack no matter how you slice it). You also get XSL, which floats some people's boats, though I wouldn't be caught dead working in it.
If you don't need any of that, don't use it. I don't very often. But when you need it, do. Also:
"An XML parser has to track open tag names, with JSON it doesn't matter."
This is equivalent to JSON needing to track {, [, ', and ", among other things. That's just parsing; both JSON and XML need to be parsed. That's not an advantage.
"XML has all stupid entities like & which look ugly and need to be parsed."
This is equivalent to the escape sequences in JSON: http://json.org/string.gif They also need to be parsed, they do not magically turn into bytes without that.