[foresto]

Free, reliable, enduring servers supporting all the XEPs needed to approach Matrix functionality were scarce when I last surveyed the XMPP landscape. This alone made it not viable for global, general-purpose use.

Also, only a tiny handful of clients supporting those XEPs by default were easy to find and set up, and I don't think those few covered all platforms, making the problem worse.

(And I don't recall XMPP ever being great at mixing offline delivery with multi-device support, since messages cached on a server weren't guaranteed to be held until all devices retrieved them, but I suppose it's possible that might have been solved by now.)

I do miss the Jabber glory days, and I might still consider it for smallish communities where I could reasonably provide the server and tech support, but I don't see it challenging Matrix as a practical choice for the world's general messaging needs.

[foresto]

Also, STUN/TURN is not sufficient to handle scalable voice and video conferencing. It would take care of NAT traversal, but can't do anything about the bandwidth problem: Each participant would have to maintain a bidirectional A/V channel to each other participant. Many residential internet connections would struggle quickly, and mobile phone bandwidth even more quickly.

Adding a selective forwarding unit could solve the outbound bandwidth problem (each participant would then only need one outgoing A/V channel) but can't help with the incoming bandwidth problem (each participant would still need to receive the A/V stream of each other participant). It can't compete with the Matrix design as I understand it.

A sufficiently powerful multipoint control unit could solve the bandwidth problem in both directions. But as far as I know, MCUs capable of handling big conferences are not cheap.

In other words, I think pmlnr's XMPP endorsement underestimates what it takes to do scalable audio/video chat.