Why both no-cache and no-store should be used in HTTP response?

I must clarify that no-cache does not mean do not cache. In fact, it means "revalidate with server" before using any cached response you may have, on every request.

must-revalidate, on the other hand, only needs to revalidate when the resource is considered stale.

If the server says that the resource is still valid then the cache can respond with its representation, thus alleviating the need for the server to resend the entire resource.

no-store is effectively the full do not cache directive and is intended to prevent storage of the representation in any form of cache whatsoever.

I say whatsoever, but note this in the RFC 2616 HTTP spec:

History buffers MAY store such responses as part of their normal operation

But this is omitted from the newer RFC 7234 HTTP spec in potentially an attempt to make no-store stronger, see:

https://www.rfc-editor.org/rfc/rfc7234#section-5.2.1.5

no-store should not be necessary in normal situations, and in some cases can harm speed and usability.

It was intended as a privacy measure: it tells browsers and caches that the response contains sensitive information that should never be written to a disk-based cache (or other non-volatile storage).

How it works:

• Normally, even if a response is marked as no-cache by the server, a user agent such as a browser may store the response. If the user agent needs to request the same resource again later, it may make a conditional request whereby the server can decide to either send an updated response or allow the user agent to re-use the stored response.

  If the server does not positively affirm that the stored response can still be used, or if the server can't be reached, the user agent (eg the browser) can't use the stored response.

• Using no-store will prevent that response being stored to disk or any non-volatile storage, and prevents the response being used in a later conditional request.

My current understanding is that it is just for intermediate cache server. Even if "no-cache" is in response, intermediate cache server can still save the content to non-volatile storage.

This is incorrect. Intermediate cache servers compatible with HTTP 1.1 will obey the same no-cache and must-revalidate instructions as browser caches will.

If the intermediate cache server does not support HTTP 1.1, then you will need to use Pragma: no-cache and hope for the best. Note that if it doesn't support HTTP 1.1 then no-store is also not going to have the desired effect.

Originally we used no-cache many years ago and did run into some problems with stale content with certain browsers... Don't remember the specifics unfortunately.

We had since settled on JUST the use of no-store. Have never looked back or had a single issue with stale content by any browser or intermediaries since.

This space is certainly dominated by reality of implementations vs what happens to have been written in various RFCs. Many proxies in particular tend to think they do a better job of "improving performance" by replacing the policy they are supposed to be following with their own.