There is pretty much nothing done in Matrix that couldn’t be done with XMPP. But XMPP suffers from multiple issues:

• The protocol is very well controlled, but the downside is it takes forever to have any extension approved, leaving sometimes features you would want fast in limbo for months, years, and clients/servers dev waiting for the extension to be finalized. The worst example is probably when Google dropped a group video implementation for XMPP in 2005 on the table, (at the time, Google messenging system was using XMPP) with source code, free license and everything. They would just have to take it and use it. Version 1.0 of the protocol extension was released… in 2009! Meanwhile, many clients were just “waiting” for the protocol before starting implementing anything. When the protocol was finalized, XMPP’s world could congratulate itself for being 3-4 years late on every other communication system. This story repeated recently with an encryption extension.
• There are many clients project, most of them are carried by 1 or 2 devs, each of them almost single platform.
• As XMPP is “older”, it doesn’t benefit from any buzz effect, and some of the “waiting for features” have worn out many adopters.

As it was said in another comment, there is a company and some investors behind Matrix, and with that:

• Protocol can change as fast as they need to implement a new feature. Worst case it is updated again later
• Having much more resources, they could develop a true multi-platform client with a quite consistent interface. That eases a lot the adoption by non-technical users.
• Being the new thing and with a bit of marketing, they had a buzz, and that leaded to more servers and more clients developed, though they all have to follow the company’s train.

Now, from a self-hosting point of view, Matrix has a huge flaw: rooms are entirely copied and synced on all servers from which a user participates. It takes only 1.

For example: if any of your users join a room with 10k users exchanging thousands of messages per day, your humble server will synchronize the whole flow in a local copy. There is not a chance a small server can take that kind of load. Last time I checked where they were for solutions (it was years ago, might be different today), the proposals were:

• Option for admins to prevent users from joining room bigger than xxx ?
• Wait for a new server implementation that’s lighter than the mainstream one? (still not released in prod to date, and won’t really solve the problem)

And for some positive points about XMPP:

• It proved its scalability. Whatsapp started as an XMPP server/client with no federation (don’t know how far they drifted from the base protocol now, though)
• It is extremely versatile. Right now, there are 2 leading project that include blogging/microblogging features and more

https://movim.eu/

https://libervia.org/

The last has microblogging, events, forum, ticket management, file sharing features, etc… Still needs a lot of love but it shows the potential of the protocol.

There are other projects using XMPP for whole different things (IoT, …)

Because a corpo is developing it (see Element)

Better marketing? Not sure…

And given #xmpp can do things like !movim @lemmy.ml, it’s a shame it’s not me widely used.