At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.
STARTTLS mixes concerns in a very bad way and is a horrible hack. Let it die with FTP and SMTP.
Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".
Faced with a choice of obtaining a TLS certificate or just going for the old HTTP/1.x protocol, it'd be a hard sell for HTTP/2 for any one-off, quick hack experiment/microsite/internal APIs...
The problem is browsers are mostly lousy at giving a good user experience with self-signed certificates. 99% of the time, self-signed doesn't matter except if the certificate changes unexpectedly - i.e. the service just isn't that important.
The 1% of sites it does matter for are things like banks and the like, where you need to hammer into users heads that certificates should be valid via other means.
Of course, it's casually accepted that it's a-ok for companies to MitM their employees encrypted connections anyway, so I don't really know where that leaves us.
STARTTLS has risks over and above pure use of TLS - in particular where it's been used in IMAP and POP3, an attacker injecting plaintext commands before STARTTLS/STLS occurs, tricking an early (plaintext) login and other such shenanigans.
This is why the SMTPS port is being resurrected, and STARTTLS-type upgrades are not considered good practice in future - port assignments in future are likely to take that into account.
