Not saying that XMPP overall is a great protocol, but you always could parse a XMPP stream with an event based XML parser (eg. a SAX parser). Yes you likely have to implement namespace resolution on top of the event stream, but it's not that hard.

I've created many XMPP implementations, and I've never created a custom XML parser for it (well, some toy ones for various fun things, but not one I'd use in production).

You're right that some XML parsers demand the entire document at once, and those are not suitable for XMPP (or any kind of incremental document parsing). Parsers with a SAX-based API for example don't have this limitation.

Protocols have many aspects, and the serialization format is often the least important among them, although it definitely attracts most attention, as it's the easiest to get acknowledged with deeply enough to be able discuss it.

XML back then (late 90s-early 00s) was quite an ubiquitous format, more popular than JSON. Websocket itself was drafted in 2010, so you wouldn't be able to come up with something better than a "never-ending stream of XML/JSON messages".

The single objectively positive aspect of XML is namespaces. It is very important for "extensibility" part of the protocol, as it allows you to introduce custom elements, which are namespaced by your org's domain name. Protocols such as Matrix [1] and ActivityPub [2] use JSON as the serialization format, but they too support extensibility, and therefore they have to implement namespacing. Which they do, but very differently.

[1]: https://spec.matrix.org/latest/#namespacing

[2]: https://www.w3.org/TR/json-ld/#the-context

Xmpp is a good protocol. Zero of its problems were caused by XML. It has many really lousy and badly thought of and mutually inconsistent extensions, but an implementation can always ignore them.

All problems XMPP has are caused by the difficult problem which is decentralized messaging. Choose JSON or binary data format and eventually you'll encounter all the same problems again and again.