Browsers store, proxies cache , so it should be no-cache, obviously!
Sure, it's stupid, but naming is hard and these things happen all the time.
That might be a little counter-intuitive, but if you read the definitions of the words, it does make sense.
> no-cache won't give you cached entry without validation
> must-revalidate, max-age=10 will revalidate only after the time has expired
must-revalidate: you MUST revalidate with the server before using this after it expires
They overlap but address different things; no-cache is for cacheability while must-revalidate is for validity. I don't think either of them are named very well.
The "no-cache" was a hint not about caching the content but about caching subsequent requests, and could optionally specify specific fields that would indicate that a new candidate request needed to be sent to the server as the content might be different. There's this reality that just to render content, the browser effectively must have a cached copy of the content, so the notion that the response wouldn't be cached wasn't really even in the cards. Whether you used the cache or not was a decision made at the time you were sending a request, not when you were consuming the response.
The "no-cache" directive meant, "hey, don't check for a cached copy of the content, just go fetch new content". It was often used by analytics pieces so that the server could count how often content was looked at.
Back in the day you had terrible latencies (particularly over dialup). You also had issues with horribly asymmetric bandwidth that meant the data you sent could become the bandwidth bottleneck (outbound bandwidth constraints would mean ACK packets would get queued up, delaying downloads even when you had plenty of download bandwidth), and of course HTTP requests weren't terribly compact, so this could really make a big difference.
Caching requests was a big deal. Performance could be improved significantly by "cheating" and just not sending a new request, and this lead to some very aggressive caching strategies. The, "check if the content really is different, and just use the original copy if they aren't" hack a pretty common one. If nothing else, it saved the browser the overhead of re-rendering the page and the accompanying annoying user experience of seeing the re-render.
The original protocol didn't have any notion of no-store, and specifically mentioned that "private" didn't really provide privacy, but more that the content should be "private" in the sense that only the browser itself should store the content. Again, there's an assumption that the browser is going to put everything it gets into a "cache", because it has to.
You could use "max-age", but a lot of caches would still shove the object in their cache and only expire it on a FIFO basis or when a new request was to be sent (and it was vulnerable to clock skew problems). Sounds dumb, but it was the kind of dumb that kept code simple and worked pretty well.
So now that the practices were in place, you need a new directive to say, "hold up, that old approach is NOT a good idea here". So they came up with "no-store" as a way to say, "don't even put it in the cache in the first place".