90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption. Encryption only really comes handy when confidential information and authentication credentials get exchanged.
Now if you provide authentication by other means, and confidentiality of the traffic not important, plain text protocols make sense because it enables caching proxy.
Typical use case: software updates distributed as signed packages. The information isn't very confidential, and using plain HTTP enables the usage of a caching local proxy.
> 90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption.
Authentication of the server is not sufficient, you also have to authenticate every message as having a valid checksum and signature.
>Typical use case: software updates distributed as signed packages
This is a specific use-case because the package checksums are verified before any of the code is executed (unlike injected javascript to webpages). Also the checksum is usually obtained from the package server, so if SSL is broken the checksum can be spoofed as well.
> Do you perhaps mean "cryptography" rather than "encryption"?
That's true the poster said authentication of the server, if you sign every message cryptographically, you'll be able to detect message tampering. I should edit that.
>Encryption only really comes handy when confidential information and authentication credentials get exchanged.
It's 2015 and we have quad-core processors in phones that are faster than my laptop. What reason can anyone possibly have to not at least strive to encrypt everything? When is it advantageous to not encrypt?
Now if you provide authentication by other means, and confidentiality of the traffic not important, plain text protocols make sense because it enables caching proxy.
Typical use case: software updates distributed as signed packages. The information isn't very confidential, and using plain HTTP enables the usage of a caching local proxy.