There's nothing lowbrow about it; it's a technical objection to the protocol and a commentary on Google's socialization of a bad idea. I'll thank you to focus on the merits of the argument instead of trying to besmirch its character.

There is nothing untenable about "the situation," because the attack you suggest has never been spotted in the wild, targets one of the less-weak links in the SMTP chain (i.e. there is lower-hanging fruit), and finally comprise a false dichotomy between "MTS-STA" and "do nothing."

All MTA-STS requires is effectively fetching a domain name and port number over HTTPS, then DNS query as usual and connect to the port. Literally nothing is gained over simply securing the MX record delivery to start with, to the degree that when someone brought this up on the IEFT draft process the response was nontechnical -- "we think people already have an https endpoint" is not how you design a standard.

DANE exists, is only onerous to learn one time, and 'world governments' are how humanity operates, in case you haven't noticed. The fact that we currently have a global PKI rooted in huge corporations is not sustainable if you want an Internet that human beings are allowed to participate in. I acknowledge that this may be a fundamental disagreement in worldviews, but your preference for corporate rule over government rule is not the correct category of consideration for standards development.

There has not in fact been an SMTP-over-TLS port "for ages." There is not one now. There is a submission-over-TLS port for MUAs, and there is STARTTLS on port 25, but there is not an MTA-related SMTP-over-TLS port specified in any standard. STARTTLS is idiocy for obvious reasons beyond aesthetic layer violations, but the MTA-STS people declined to address in a technical manner their lack of support for SMTP-over-TLS port standardization, providing instead a set of assumptions about what other people might or might not know. Again, terrible. And again, exactly your argument here.

MITM attackers can RST connections to MTA-STS-specified ports just as well, and I question your implied assumption that MTA-STS somehow protects against this: it does not.

MTA-STS does not explicitly require every message to do anything; it requires MTAs to do all this legwork, and less wealthy operators can just pay for the bandwidth, right? Transport is free, of course -- at least if you were on the MTA-STS design committee.

Basically, every single defense of "MTA-STS" as a solution rests in the root of "we think fixing DNS is hard" and that is exactly the failure of vision I spoke about earlier. You've consistently expressed this view and I do not expect that you'll change your opinion, but copping out because things might be difficult is the wrong answer. Letting megacorps drive standards processes, rejecting every single attempt to collaborate that came from outside the ivory tower, and then telling us it's for our own good (because our poor little low-brow brains can't possibly fathom how nameservices work) is terrible, terrible policy.

MTA-STS is a failure of vision, a failure of process, and a failure of our industry. In the long run, it's a minor one, but it so purely and cleanly exemplifies the root causes of the de-democratization of the Internet that I feel strongly about calling it out as the failure it is.