I think you mix up opportunistic encryption as described by these drafts and STARTTLS.
STARTTLS has clearly defined semantics how certificates should be verified (see RFC6125) and most Mail User Agents (MUA) implement these validations when connecting to an Mail Transport Agent (MTA). Thus you need to explicitly accept a specific fingerprint of a server if the certificate is signed by an unknown CA. Most MTAs instead offer ways to disable these validation checks, with the argumentation that non-validated TLS helps against passive monitoring in thus is at least better than no TLS at all.
But, the security model of mail (SMTP) is totally different from HTTP. SMTP is a hop-by-hop protocol with at least on MTA between source and target MUA. There is no end-to-end encryption (i.e. MUA-to-MUA), but only hop-by-hop. This means any MTA in between can see and modify the mails in plain text, even if the connection to this MTA is protected by TLS. So if you need privacy with SMTP you need to encrypt the body of the mail yourself - that's what PGP and S/MIME are for.
HTTP instead provides an end-to-end connection between the parties and HTTPS thus offers end-to-end encryption. There is no additional security layer defined (e.g. similar to PGP or S/MIME) so your privacy solely depends on the proper implementation of TLS.
Have a look at the section about security considerations in the RFCs you referenced. They both clearly state, that they only protect against passive monitoring, that they are vulnerable to man-in-the-middle attacks, and that browser creators should not provide a user interface which might suggest a protection comparable to HTTPS.
And about your complains about the "cartel" associated with HTTPS: There is nothing inherent with TLS/HTTPS which needs such a "cartel". But, what it needs is a way to validate the identification (certificate) presented by the peer, because otherwise it would be vulnerable to man-in-the-middle (active) attacks. Historically this validation has been implemented by having a fixed set of trust anchors in the browsers and start from there to validate the certificate. If you have another trusted way to verify the servers certificate you can use it, but at the end it does not remove the need for some kind of trust anchors, but it only replaces it with other trust anchors. Like with DANE, where you need DNSSec which again needs trusted CAs for signing the DNS root entries and build a trust chain from there to verify the DNS entries which include the certificate.
I would not suggest, that the current way with 100s of fully trusted root-CAs inside the browser is the way we should continue. But at least it provides the expected security in most cases. So I would not recommend to replace it with something far worse, i.e. one of these drafts which provides encryption without identification of the peer. I would not even recommend to implement this as an option inside the browser, because the average user will not be able to understand the differences between the various levels of security.
