To this day plenty of documentation refers to STARTTLS as being the preferred way of configuring your email client. This is _clearly_ insane in the face of implicit TLS existing. I've never understood why STARTTLS is recommended over implicit TLS.
I think it was because of corporate firewalls. Unencrypted ports for POP3, IMAP, and SMTP were widely known and allowed where necessary, but their implicit-TLS counterparts were often blocked and IT departments were slow to adapt. STARTTLS helps you smuggle an encrypted tunnel over a well-known port.
Nowadays, it's often the reverse. Many clouds block outgoing port 25 by default, and sometimes even 587. But almost nobody blocks port 465 -- the assumption is that if you're using 465, you must be authorized to use that server -- so that's the port you must use if you want to send emails by SMTP from a typical cloud server.
There was a sense of "wasting a port". A modern Linux /etc/services has only 200 or so reserved TCP ports (out of a possible ~50k) so that fear might have been overblown.
I suspect the bureaucratic overhead of needing to go to IANA to reserve a new port might have had a chilling effect. See:
This makes sense, because perhaps the world's most important email client that still costs money to buy (Outlook) used the terms SSL and TLS like that for about a decade. These days the toggle says "SSL/TLS" versus "STARTTLS", I believe, or they may have even dropped the toggle completely to just auto-detect the protocol based on the port number.
Using correct terminology would've led to tons of unnecessary helpdesk calls because Microsoft messed up its naming scheme.
