For some reason it is probably not (I am not immediately fully sure but I think it redownloads all the time). It might be something to recheck and potentially an issue on its own, but there is at least one legitimate case when wininet caching won't help. That is, when the request fails to get response for whatever reason (outdated ocsp link in certificate which happens; other reasons why request fails, like currently we have a bug when the request is wrongly built for http://ocsp2.globalsign.com/rootr3 where it doesn't handle /rootr3 path in URI and omits it; possibly other cases). Currently in such cases, even if we successfully fallback to CRL and cached the success, we will repeat OCSP part first on each revocation verify request. And that is quite lengthy process.
So it seems to me that just checking valid status is something we need to do regardless to avoid lengthy process in case of http(s) requests failures (that is, the first patch). Then, the second patch is indeed should not be saving that much provided wininet cache works, but at the same time it looks simple and unifies the revocation caching. Maybe it still makes sense to have it? Also, we are probably on the mercy of the server here, what if, e. g., it is specifies no-cache while response itself has NextUpdate in the future?