I like the idea conceptually, but what is the likelihood of broader adoption? I notice that Meta, Apple, and Google are conspicuously absent from the contributors. Historically (see e.g. Matter) it seems like standards that aren't written to conform to existing de facto implementations tend to be superseded by later ones that are.
I'll admit to not having read the entirety of the RFC, but I'd also be curious about how the proposed approach maps to the current privacy/UX goals that the established players are pursuing, e.g. if WhatsApp wants to preserve cleartext moderation of E2E group chats, is that possible under this scheme, etc.
Meta preceeded Google in killing XMPP. I'm hopeful but cynical: companies have people on standard's committees for all kinds of other reasons, e.g. for prestige.
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.
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.
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.
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'll admit to not having read the entirety of the RFC, but I'd also be curious about how the proposed approach maps to the current privacy/UX goals that the established players are pursuing, e.g. if WhatsApp wants to preserve cleartext moderation of E2E group chats, is that possible under this scheme, etc.