There are more peculiarities with XML, e.g., the ambiguity of attributes vs nested elements (you could also write <name="John"><age>20</age></name> to express the same thing) but these don't feel insurmountable. You could pin down a subset based on extra rules that would simplify working with XML/XHTML and obviate the need to invent a parallel universe in the form of JSON.

You mention the data/presentation mix and that is not necessarily an advantage - separation of duties is usually a good idea, unless you can properly channel that "efficiency". But that too seems not insurmountable: the real, visual presentation on screen is anyway delegated to CSS. The (X)HTML structure is still in a sense supposed to capture the logical structure of the document/object that is being transmitted. What would be required is a way for the client-side language to distill the data-centric logic from the occasionally inflationary use of things like <div> elements (which seems another hack trying to fix poor design anyway).

In any case, no point crying over spilled milk. The winner-takes-all nature of the web means it is doomed to be building on the hacks adopted by the dominant entities to solve their needs. A historical accident that keeps giving.

Who knows, maybe as the browser is enabled with WASM and whatnot there will be a chance in the future to have a more rational approach to API's, REST, Hypermedia, Linked Data and that magical universe.

I often see variants like this in xml:

<item> <Name>John</Name> <Age>20</Age> </item>

or <item_John age="20"/> where john is parsed manually out of item object

or full blown up insanity <person> <item> <key>name</key> <value>John</value> </item> <item> <key>age</key> <value>20</value </item> </person>

> <name="John" age="20" />

As far as I know, that is not well-formed XML; the tag name is missing. You'd have to write it like this:

<person name="John" age="20" />