I was more trying to say that XML is better for heterogenous trees because XML's default is a tree structure. XML parsers default to a tree representation of your data (we use python's ElementTree, for example), JSON parsers don't. XPath is designed to be a tree navigation language. CSS selectors are... also designed for navigating XML. No equivalent exists for JSON that I know of.
Obviously, we could use JSON or YAML or S-Expressions for representing something like a parse tree, but none of them have the same robust tool chain for tree manipulation that XML has.
How could they not? It's JavaScript Object Notation. Objects which refer to sub-objects form a tree.
As to CSS selectors for JSON: the same functionality can exist, because as per above they have literally identical capabilities for representing data. I'll readily admit though, I've not seen one (though one of my side-projects could probably be tweaked to do this; maybe I will).
I have nothing against XML. It's useful, widely supported, and has quite possibly more tools than any other interchange format. The problem isn't with XML, it's with the inconsistencies of (and between) those tools that make the whole interchange part of XML with specs (the only really useful part - it's a horribly wasteful storage format) almost a moot point. And due to legacy systems, it's unlikely to change any time soon, or perhaps ever.
So a clean break is likely necessary to really improve things.
Obviously, we could use JSON or YAML or S-Expressions for representing something like a parse tree, but none of them have the same robust tool chain for tree manipulation that XML has.