1. We don't do embrace, extend and extinguish. All we do is open-source, with products available to download, and docs fully available.
2. We don't 'outright reject OMEMO capability'. I reject OMEMOdiots who moan excessively because their wishes aren't satisfied on the spot.
Why are not they satisfied? Because XMPP does not have a reliable control of message delivery, no way to remove messages from message archive, no good group chats, no client sync protocol, no way to revoke session tokens, no way to know which messages in archive were read, no way to add reactions to messages, no way to do threaded conversations, and while we're building all that we're constantly attacked by individuals who demand us drop everything we do and urgently add OMEMO so they can feel safe (and do it at our own expense, of course).
We'll provide some E2EE capability, but only after we are finished with everything else that we consider more important than this.
3. Extending XMPP in incompatible ways, I'll cover this a bit.
Do you even remotely imagine an amount of shit an XMPP client (say, a web client with no stored history) built on 'compatible' XEPs must do to display a telegram-like interface, with all the recent chats? How much time does it take? Best result we could achieve in our web version with 'compatible' server and 200 contacts is like 5 minutes. With our custom XEPs, it's currently down to 15-20 seconds, and our goal is to trim it to 3 seconds. Does it break anything with s2s? No. It only adds methods of how a client interacts with a server, that's it. Does it break legacy clients? No, they still can do it the old way, if someone is willing to wait 5 minutes.
Next, we have our group chats. They are powerful: archive search, moderation, anonymous mode, public mode, pinned messages, replies, mentions, extremely agile restriction/rights management. They are very easy to implement (on a client) and provide a nice fallback compatibility for any XMPP client even without support for them. You don't need support on participant server to use it (not as in MIX, to say). You can chat using multiple devices, with legacy clients alongside supporting clients, all working nicely with simple Carbons.
Documentation for all improvements is open, (it's not in english yet, but we're getting there), implementations are open-source and distributed under GNU licenses. No, I don't think your point about extending in incompatible ways is valid.
Probably, the more correct way to call it is that we are forking XMPP. Like, in git. We'll be sending XSF pull requests on every XEP we create - hopefully, one day XSF will come to their senses and see that their platform is fading into obscurity and irrelevance, and that to prevent it from happening they should do something differently.
