Hey, author here, the one who wrote that funny little "Various fixes, clarifications and general improvements." change :) Thanks for your interest in and analysis of OMEMO, I saw your toots on Mastodon as well.

First of all I'd generally recommend to interact with the community in cases like this, we have all the good stuff such as mailing lists and chat rooms where you could've gotten quick answers to your concerns that would have avoided a lot of the heated FUD in this post ^^

Now let me address your major points. I'm going to call all versions 0.4.0+ "OMEMO 2".

1. Protocol Freeze:
We wrote OMEMO 2 for two reasons: 0.3.0 depends on libsignal, which isn't optimal for an open ecosystem like XMPP, and 0.3.0 can only encrypt the actual text in messages and not things like read receipts or reactions. OMEMO 2 fixes both of that. Notably, 0.3.0 is not broken or insecure in any way. OMEMO 2 simply adds the neat new feature of being able to encrypt a lot more than just the text, but it's really just a comfort thing. That's why most of the unpaid open-source free-time devs don't rush to support OMEMO 2, it's _neat_ but really not essential. But I'm very much looking forward to it too, hope we can make some implementation progress soon :)

2. YOLO Crypto:
The major point that needs addressing is probably the 0.7.0 change that adds truncation. No, I was not trying to kid anybody with my changelog message, in fact I 100% stand behind it. Adding the truncation was a fix/clarification, it was supposed to be there in 0.4.0 but wasn't. You've already mentioned the fact that the XEP is experimental and the kind of responses you expect, so I'm sorry for this, but there's no way around it ^^ This specification is _experimental_, work in progress, not every single change should be considered a fully-fledged "version" and doing a cryptographic comparison between e.g. 0.4.0 and 0.5.0 has no practical relevance. We wrote 0.4.0 without a _single_ implementation, so naturally when the first unpaid open-source free-time dev got to work a few months later, oversights were found. This is what experimental is for, this is why the XMPP standards process requires implementation experience before moving a XEP out of experimental. It might look like there were a lot of "versions" with relevant differences, but really there are only two versions: 0.3.0 and its successor OMEMO 2, the current version. Everything in between is just like a dev branch commit history of the path to OMEMO 2.

I personally don't think a lot of rationale is needed for the design choices in OMEMO 2. We try to do what Signal does and recommends, such that we can benefit from the exposure and analysis that libsignal has received. If there's anything that doesn't seem to be explainable by that, please ask :)

(By the way small fun fact, libsignal truncates the HMAC to 64 bits even though their own spec calls that questionable)

3. Market Penetration:
You are comparing a specification to a product. You could right now build a product based on XMPP+OMEMO that, exactly like Signal, can only communicate with other Signal users and always has encryption on. That's totally possible and might even exist already :) What you are doing here is like criticising the SSL specification for the fact that there are websites served in plain. XMPP is used for a _lot_ more than your Signal-replacement instant messenging app. XMPP is used in controlled environments such as video game chats where chat MUST not be encrypted to allow for moderation. XMPP is used in IoT where the server is self-hosted, trusted infrastructure, and end-to-end-encryption is neither required nor possible to implement on constrained embedded devices.

Something that also needs to be mentioned here is that there are valid reasons _not_ to want OMEMO, for example the fact that messages can only be decrypted once, so if you get a new client you can't fetch your old message history. This is, again, a tradeoff that products such as Signal can choose to accept, but it is not a decision for XMPP as a whole to make.

4. Conversations:
I don't want to and also can't say much about Conversations.

Conclusion:
I hope this clears up a few things :) Happy to answer questions but preferably in a less condescending tone, we're all just people dedicating our free time to free software.