XMPP does have this feature parity issue, though there is a good selection of modern active XMPP clients across platforms with important features like end-to-end encryption and calls. But you're right - there's no way to stop people trying to use clients like Pidgin, which have been essentially frozen in time for a decade.
Matrix is newer, so has less diversity, and lots of resources to put into the Element clients. However there certainly is exactly the same problem growing in the Matrix ecosystem too - there are many features supported by Element that are not (yet?) implemented in popular alternative clients such as FluffyChat.
The best you can do is ensure that when two clients communicate without the same set of features, that you degrade gracefully and securely (e.g. the worst case I can imagine would be E2EE that silently becomes unencrypted if not supported by your contact - thankfully that's not how it's done) to the best common feature set between the two.
Instead of "oh MS teams supports up to xmpp2017" it's just a crapshoot.
Compliance suites are reviewed, updated and published annually with the recommended set of features across a range of different categories.
Looks like it's on the list but as "* Support can be enabled via an external component or an internal server module/plugin."
So...a crap shoot, haha.
...ever heard about "the state"?
Yes I know, since Matrix there is now an extension that defines a selection of extensions to try to overcome this
I use XMPP to send e2ee messages to friends on other servers and clients every day, so it's very much not just 'in theory'.
Most users would have the same level of security as with e2ee by simply running their own server. E2ee mostly helps against service owner you don't trust, so just be your own service owner and have nicely syncing history and server side search.
I suppose I could run the service on a machine in my house, but that's not going to be good for uptime, the NAT screws things up, etc. Plus, even that could be hacked if I fuck something up.
(But but chats are surely the holy cow and must be encrypted - strictly demand those same users, paradoxically)
And no modern server stores passwords in plain text, and keys are not stored on servers at all.
I will say, that even though I kind of like the architecture of XMPP better, the Matrix people have put in tremendous amounts of work to overcome the UX problems with e2ee, in particular the multidevice problem (where I have a laptop and a phone logged into the same account and try to participate in the same encrypted conversation from both).
That is only for OMEMO (OpenPGP and OTR require nothing of the server) and you can easily check a potential server for the things that OMEMO depends on by doing a normal server compliance check here:
* https://compliance.conversations.im/
In the same way, if you pick a client that does not support something then that thing will not work. But why pick such a client in the first place?