Briefly, cookies can't be cached by public caches, but since public documents may make up part of a "stateful dialog", and in particular the first document in a stateful dialog may be (for example) a public and cachable home page, servers that wish to receive the client's cookie on each request, or to issue a new cookie on requests for a document must set the document up to require validation on each request. (e.g., by having it be "pre-expired").
Otherwise, the cache control headers for responses control what a proxy has to do. If a document is fresh in a cache, a request containing a cookie does not have to be forwarded to the origin server, since (by definition) if the document is servable from a cache, there aren't important side effects at the origin relating to requests for that document, and so, no changes to the cookie.
One important issue bearing on caching is that for conditional requests that go through to the origin server, for which the origin server responds with 304 and also with a set-cookie header, caches must splice the set-cookie sent by the origin server into their own response. This is, for example, how it can work to have a home page that is in a cache, but stale, so that the only traffic to the origin server is to validate the home page, receiving a 304 and potentially a new cookie.