I'm sure there was a question in there somewhere, but I'm not seeing it. I'm the author of the article that you're responding to. I'm happy to answer questions that I can parse as such.
You can do a lot better than OMEMO. Just use a serious secure messaging application: Signal or Wire are both fine options. Virtually every secure messaging application, including OMEMO, is better than attempting to make email cryptographically secure.
I didn't have a question, though perhaps not quite seeing where those advices are coming from (what are the threat model and underlying assumptions) can be stated as a question, as well as the definition of "better" here. For instance, phone number exposure and centralized systems (in case of Signal) or unreliable message delivery (in case of OMEMO implementations) seem rather bad to me, while properties such as deniable authentication seem to be useful in rather specific and rare cases (they still wouldn't harm if they were better supported though). It's also challenging to use OpenPGP, even with widespread email usage and the standards being around for a while, since people rarely care about encryption, and the most common case (AFAICT) is to send just plaintext emails with private/secret data. Given that, it seems counterproductive to advice not using it, but using systems with more obstacles instead. Do you view some of the properties they add as particularly useful in common cases, and/or as worthy trade-offs?
You can do a lot better than OMEMO. Just use a serious secure messaging application: Signal or Wire are both fine options. Virtually every secure messaging application, including OMEMO, is better than attempting to make email cryptographically secure.