These days, I mostly use JSON, but XML is pretty much an ironclad data definition and transfer protocol. You can define and transfer just about any type of data, using it, albeit, in a rather “prolix” manner.
I suspect that may be why you might not have liked it. XML is not a good serialization of data for network protocols. XML is a good serialization of documents. Ok, that's the received wisdom that I'm echoing, but it's also my experience and my opinion.
When it comes to serialization of data for network protocols there are and have been many other better-suited schemes. XML got used as a serialization protocol for the the web because it's what existed at the time that was... close to HTML and textual, but it's got the disadvantage of being verbose.
Most XML parsers are structured to parse and deliver XML in element-delimited packets, in asynchronous fashion. I don't know of many JSON parsers that can do the same. They do exist (I use one, in the backend of one of my projects[0]), but they aren't as common. XML has packet/async built into OS SDKs, but JSON tends to be "The Whole Nine Yards" handling.
With Big Data/ML, I'm surprised that this is still a thing.
[Meaning stream parsing.] Yes, but typically one does not need that for small messages. I see that streaming decoders for Protocol Buffers is a thing now, but historically one does not bother with streaming for small messages, instead one streams lots of small messages.
> I don't know of many JSON parsers that can do the same.
libjq has one. With jsonlines or similar, if each text is small, there's no need for streamed decoding. Typically a DB query will produce a sequence of lots of small JSON texts, not one very large one.
If you're updating a DOM from XML then stream decoding makes sense, but in many cases streaming isn't ergonomic, just necessary when dealing with large documents (e.g., if there's not enough memory to hold them in memory without thrashing).