While writing an answer to this question on Server Fault, a thought that has been bouncing around my head for quite some time resurfaced again as a question:

Is there ever a good reason to not use TLS/SSL?

To further elucidate the question, I'm asking about the specific case in which things have been configured properly:


Performance:


Time to First Byte has been optimized.
The cipher list is small enough to avoid multiple roundtrips from server to client.
For mobile web applications, 2048 bit RSA server keys have been used as opposed  to 4096 bit keys to lessen the computational load on clients.
SSL sessions have a reasonable lifetime to avoid regeneration of session keys.

Security:


Perfect Forward Secrecy
Hardened Cipher List
Don't use obsolete and insecure protocols like SSLv2 and SSLv3 (if possible; not using SSLv3 means that IE 6 can't access your site).



If done properly, is there ever a good reason to not use TLS/SSL for TCP communications?

The main issue with HTTPS everywhere is that it basically makes caching web proxies useless (unless you have trust the proxy and have it impersonate sites for you, but that doesn't work with certificate stapling and is possibly illegal in some jurisdiction). For some use cases, like for example the distribution of signed software update, HTTP makes perfect sense. If you have e.g. a hundred workstations behind a corporate proxy, them downloading update with HTTP will mean for all but one it will be delivered off the proxy cache. That will be a lot more efficient that each of them doing it over HTTPS...

In short, HTTP makes sense as a transport layer if another mechanic is there to verify the authenticity and integrity of the content, and if confidentiality is of little importance...

For web browsing by actual human beings, I find it very hard to justify not using HTTPS in this day and age.
