👍
The domain authentication is part of the core protocol, the latest version is defined in RFC 6120, you can see an overview in this example.
The core protocol does not define E2EE, as this is layered on top. OMEMO has been audited, it's based on the protocol that Signal uses, and it's documented in XEP-0384.
There is a very common misconception that XMPP's modular design (i.e. having XEPs) is a bad thing. I strongly disagree - this modular design has allowed us to evolve XMPP over the past 20 years and keep up with changes in security and technology. If you're curious, I wrote more about it in this blog post, Products vs Protocols.
If we didn't have XEPs, we would have needed to throw XMPP out and make a new protocol as soon as end-to-end encryption (or any other feature) became a modern requirement. Throwing out a whole good open protocol that is widely used simply makes no sense.
Finally, just because something is a XEP doesn't mean it has to be optional. Just like you could use a web browser that doesn't support HTTPS, it doesn't mean the web is broken and we need to rewrite it from the beginning! No, we just upgrade to web browsers that support HTTPS. In fact web browsers are now moving to require HTTPS by default. It's the same with XMPP - all modern clients implement E2EE, and this is great. They will either refuse to downgrade to non-E2EE (e.g. Quicksy) or very clearly tell you if E2EE can't be established.
Anyway, I hope this comment and the blog post helps clear things up!