I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission):

    Connection to smtp.comcast.net port 587 [tcp/submission] succeeded!
    220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready
    EHLO [2601:b:x:x:x:x:x:x]
    250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you
    250-HELP
    250-AUTH LOGIN PLAIN
    250-SIZE 36700160
    250-ENHANCEDSTATUSCODES
    250-8BITMIME
    250-STARTTLS
    250 OK
    AUTH LOGIN
    334 VXNlcm5hbWU6

That's right, the customer-facing SMTP server for the largest ISP in North America will happily let clients authenticate via base64-encoded plaintext without doing STARTTLS first.

At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?"

If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.

With respect to the RFCs, it's not required to issue STARTTLS before AUTH so that's probably why billyhoffman said "optional". One is certainly free to use authentication without requiring encryption although, in practice, I'm not sure why you would want to do that (with an exception being when all MUA -> MTA traffic remains entirely within a private network, perhaps -- but even then, why not add encryption just for good measure?).