No, this RFC doesn't address that -- as illustrated in the title ("...for Email Submission/Access").
As mentioned in section 1 ("Introduction") of the linked RFC:
This memo does not address the use of TLS with
SMTP for message relay (where Message Submission
[RFC6409] does not apply). Improving the use of
TLS with SMTP for message relay requires a different
approach. One approach to address that topic is
described in [RFC7672]; another is provided in
[MTA-STS].
RFC6409: https://tools.ietf.org/html/rfc6409
RFC7672: https://tools.ietf.org/html/rfc7672
MTA-STS: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-14
Of course, they could have gone with DNSSEC, but HTTPS has the virtue of solving the same problem (modulo proper configuration), while also being more widely deployed and better understood.
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.
For message relaying, your proposal might indeed work. The vast majority of inter-domain mail traffic goes through a very small number of providers. No mail provider can afford to not be able to exchange mail with gmail, or office365, or ...
It is trivial to set up a mail server with TLS and if you don't have fucking TLS bounce it through a protocol upgrade server. If you understood the type of secrets that are getting trivially intercepted you'd realize that a couple hard days for a couple of lazy sys admins is a tiny price to pay for the drastic increase in security.
People are literally getting killed because we're so fucking lazy. Even three letter agencies are sending mail without TLS, this is madness.
Anyone running that mission critical hardware is free to keep using insecure email, no one is going to stop that. If they really need to send email from that old hardware to gmail, they can set up their own relay that accepts non-tls connections but relays using TLS.
What the big sites can do is add a delay when receiving from a plaintext relay, in a manner similar to greylisting and tarpiting that are widely deployed. The mail is not rejected, just delayed. The delay can be proportional to the amount of mail sent by a domain, and set to increase in time. The same can be done for outgoing mail to domains that don't advertise STARTTLS, drop the connection and retry later.
In the first phase, just issue a warning then drop the first submission attempt, to fillup the logs with a clear message that STARTTLS is strongly preferred. Gradually increase the delay so that large sites have trouble emptying their queue, and continue to increase the delay until the last holdouts can be simply shut out.
The advantage with this approach is that the user of Gmail, Yahoo etc. does not see a problem with his account, while the smaller sites and users will have delays when sending mail and receiving mail and be forced to take action.
It's essential that the major email domains work together so that the users of small non-encrypting domains feel a generalized performance impact, not just a problem with Gmail or just Yahoo.
The IETF UTA working group has documents in process to address the mail relaying case; I'm sure they'd appreciate review and feedback.
But this doesn't seem to touch on transmission between email servers at all, and that needs to be addressed as well. Email can be submitted protected by TLS, but if it has to cross the Internet in the clear to reach its recipient, then all you've succeeded in doing with submission/access TLS is prevented your user's login credentials from leaking. You've not done much to protect the confidentiality of your user's correspondence. Understand, I'm not denigrating the importance of TLS for submission and access, but it's also not the whole picture.
Yes, you can set your SMTP server to opportunistically use TLS when the other connecting SMTP server supports it as well, but not all SMTP servers do. Mandating TLS makes those servers that don't effectively unreachable. I seem to recall Facebook doing a study about it. The Postfix documentation warns about it as well.
I'm not sure I have a good solution here, other than something akin to the linked RFC: a proposed standard that gives a deprecation/sunset period to transition to mandatory TLS. The problem then, is getting majority compliance during that period. If the IPv6 transition is any indication, that's likely to be an uphill battle, as mandatory TLS between SMTP servers would break a rather large installed base that's presently working just fine.