A generic XML DOM is still complicated to deal with. Even if you do the "right thing" and use XPath, you still have to deal with XPath because you can't get around the fact that you have an underlying representation that has at least two dimensions (attributes vs. CDATA). That is, just as the article says, you have more degrees of freedom in how you represent your data, and what is a "degree of freedom" but a near synonym of "dimensionality"? You can't abstract around dimensionality very effectively without losing fundamental capabilities in the underlying component (in fact a staggering number of abstraction failures in general can be shown to come from exactly this problem if you really learn to think this way), and the complexity comes poking out in the XPath. It's still better than groveling over the DOM yourself, but it's probably also the absolute peak of concision that is obtainable; there will be nothing better.
JSON is indeed simpler in that you don't really have 3 or 4 feasible choices per attribute; {"first-name": "John", "last-name": "Smith"} is pretty much your choice, full stop. That leaves the underlying library fundamentally, not accidentally, simpler. This can get you into some trouble in some cases, for instance XML is a better choice for HTML-type tagged text as the JSON for tagged-text is just hideous (and, interestingly, reopens the dimensionality problem as there is no one obvious solution), but many things are fundamentally simpler than tagged-text.
If you want to pick up a defined serialization format, my gut would be to say to default to JSON and back to XML if you really need it for something... but be aware that you may, and it's no better to try to jam JSON on top of a fundamentally XML problem. (Besides, your JSON can carry bits of XML in it without much pain, so "best of both worlds" is perfectly feasible.)