It used to - browsers wouldn't cache anything by default if it came over https (you could send a 'cache-control: public'header to get it to though). As far as I can tell, these days almost all browsers have changed their policy so you don't have to do that now.

It does completely disable ability for your ISP to have transparent proxies caching content a before it's sent to you, but the security and privacy gain is worth the trade off.

What about for your server-side stuff? Like caching in Varnish?

Varnish doesn't do HTTPS... so you have to put something that does SSL in front of varnish, which sits in front of your real web server:

SSL -> varnish -> backend varnish -> backend

You can do the SSL before Varnish, then it makes no difference.

Does that work? Each client has its own key, so your caching goes from "one cached copy for everyone" to "one cached copy per client", right? Or am I missing something there?

No, you could still have one cached copy for everyone. The SSL termination happens before the user's request gets to the caching server. As far as the cache is concerned, it is a regular http request. The only problem is you cannot have generic caches that live closer to the end user; the cache has to be controlled by the person controlling the SSL termination.

So you're talking about caching the cleartext and then encrypting it for each client, which is totally doable.

I (possibly mis-) understood the original comment to be claiming that you could cache the ciphertext, to which I just wanted to make sure I wasn't missing some huge piece of understanding.

Yes.

There's work underway at the IETF to define a standard for signing pages and included resources, so that caches can do their business while still providing the same authenticity features as an HSTS-compliant site. I can't seem to find a reference to an RFC right now, though, unfortunately.