HTTPS does not provide authentication sufficiently well to put every egg in its basket.

As for "better understood," the authors of this standard work for Google, Verizon, Microsoft, and Comcast. Combined they probably serve most of the email in the western hemisphere.

There is no excuse for overcomplicating a proposed standard -- and "we have this stuff lying around" is no exception. This plan has the effect of causing a networking protocol to depend on an entire series of unrelated networking protocols.

It does not bode well for the future of independent email operators and it provides no path forward for integrating existing devices. It pushes many, many extra steps onto client devices, necessitating entire additional libraries of software to deal with them. That's not a problem for companies with tens of thousands of developers at their beck and call -- but it is only going to raise the barrier-to-entry of operating an independent service.

Those sound like reasonable objections. Are you posting them to the discussions involved in shaping and ratifying the proposed standard?

What does https do that's different from verifying the cert chain and matching the cn to the hostname? Is this about the ill-conceived cert-pinning that pretends distributing keys for every domain is a scalable alternative to certificate authorities and on-line revocation lists?

An MTA-STS web server is also used for policy discovery, and the HTTPS requirement ensures that the policy is authentic.