Theoretically it would be feasible with something like STARTTLS that allows to upgrade a connection (part of SMTP and maybe IMAP) but browsers do not support this as it is not part of standard HTTP.
It actually is part of standard HTTP [0], just not part of commonly implemented HTTP.
The basic difference between SMTP and HTTP in this context is that email addresses do not contain enough information for the client to know whether it should be expecting encrypted transport or not (hence MTA-STS and SMTP/DANE [1]), so you need to negotiate it with STARTTLS or the like, whereas the https URL scheme tells the client to expect TLS, so there is no need to negotiate, you can just start in with the TLS ClientHello.
In general, it would be inadvisable at this point to try to switch hit between HTTP and HTTPS based on the initial packets from the client, because then you would need to ensure that there was no ambiguity. We use this trick to multiplex DTLS/SRTP/STUN and it's somewhat tricky to get right [2] and places limitations on what code points you can assign later. If you wanted to port multiplex, it would be better to do something like HTTP Upgrade, but at this point port 443 is so entrenched, that it's hard to see people changing.
> In general, it would be inadvisable at this point to try to switch hit between HTTP and HTTPS based on the initial packets from the client, because then you would need to ensure that there was no ambiguity.
Exactly my original point. If you really understand the protocols, there is probably zero ambiguity (I'm assuming here). But with essentially nothing to gain from supporting this, its obvious to me that any minor risk outweighs the (lack of) benefits.
