I upvoted you: everything in your comment was correct, on-point, and good advice. I'm more worried about all the people who don't follow the best practice. I know a guy who used to run web servers for dozens of clients, who didn't know about HTTP headers before I told him.
For what it's worth, in-memory caching is a totally different animal. You can expect the in-memory cache to keep a typical object for minutes or hours, depending on usage patterns. You can expect the disk cache to keep a typical object for days or weeks, across browser restarts and even system reboots.
If this caching allows a website to switch from using HTTP to HTTPS within its budget, then I think the net effect is very positive. We can't have bad website administrators/developers holding back real security improvements with their incompetence. Really, caching is a very small security impact compared to other problems that such an administrator is likely to cause.
Again, absolutely right. Remember, though, that we're not talking about the capability here: we're talking about the default. A (well-run) website can get all the caching benefits by including a HTTP header. The article is about a well-run website that does exactly this. The default only matters at all for poorly-run websites.
Given that poorly run websites are considerably less likely to be worried about scaling issues, the caching is mostly inconsequential. So, would we prefer to give the poorly-run website a mostly inconsequential security benefit or a mostly inconsequential scaling benefit?
For what it's worth, in-memory caching is a totally different animal. You can expect the in-memory cache to keep a typical object for minutes or hours, depending on usage patterns. You can expect the disk cache to keep a typical object for days or weeks, across browser restarts and even system reboots.