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

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.

I don't agree with the response of @valentinas. There is a performance loss with TLS. If it is relevant for you depends on your site:

• To establish the connection you first have the TCP handshake between client and server for both HTTP and HTTPS, which needs one full round trip between client and server.
• For HTTPS you additionally have the TLS handshake which needs two round trips on the initial session establishment (only one if TLS false start is supported) and one round trip if you can resume a session.
• While the symmetric cryptography used inside the TLS session is cheap, the initial key exchange is not. If you do it right you want to use forward secrecy, which means either DHE or ECDHE. Simple DHE is very expensive to set up, ECDHE is much cheaper but not all clients support it. See http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html for benchmarks.

These things combined make TLS connections more expensive to set up and thus introduces a noticeable performance hit with short connections. More hardware will not help much, because the major problem are the additional exchanges between the peers, where they have to wait for each other to continue.

With long connections this overhead does not matter that much anymore, so if you use keep-alive (most clients and server do) and have only few connections you probably will be fine. But, few connections means that you should not include any ad-networks, because they often redirect between multiple hosts until they reach the one which finally serves the advertisement. Sites which heavily depend on advertisements are already slowed down by this (initial round trip for TCP) but they will be more slow if they switch to HTTPS, because of two more round trips needed to establish the TLS session to each of the servers in the advertisement chain.

A reason I haven't seen mentioned yet is that, as archaic as it may sound, some clients may not support TLS/SSL. This is a specialized case, for sure, and usually involves either embedded or legacy systems, but unfortunately some still do exist.

The first example that springs to mind is a custom microcontroller we were using, where we'd underestimated the amount of space we'd need, and weren't going to be able to include the size of an SSL library. We ended up needing to cut it out and communicate over standard HTTP instead, and were quite thankful that the server this had to pull data from offered both methods.

Also ran into a legacy system a few years back that prevented the use of TLS/SSL. A project a friend of mine was hired for involved setting up a remote web server and a automated client at a university. The client script was running in an antiquated and heavily sandboxed environment at the university - every part of compilation was handled by an automated system, and the set of libraries that could be accessed was a hardcoded list.

Are these common enough to warrant avoiding TLS/SSL in normal cases? I'd say no, but there are times when they can be important. If you're writing software primarily meant to communicate with embedded systems, I'd think twice before offering only TLS/SSL.