However, you can configure a proxy to intercept and re encrypt things. But the client (your browser) must trust the certificate that's re encrypting, which won't happen unless the proxy's CA cert is installed on your system. This most often occurs in corporate environment, where they control the endpoints.
Of course, if you're not careful, the proxy can do sslstrip and such, tricking users into not using/checking https. But if you're careful and check for HTTPS, you're OK in theory (assuming TLS works, no vulns, etc).
They say it is just for caching purposes (if the html data is encrypted they cannot serve cached images and so), but who knows what they do with your data as credit cards, etc.
If a man in the middle proxy decrypted the content and re-encrypted it, it would be using a different public key than the one that belongs to the original website, and your browser would know immediately and warn you, probably also preventing you from even loading the page.
The proxy would have to be trusted on your computer as a Certificate Authority, at which point you've given the proxy the power to say "trust me, this public key really does belong to Google". Even then, in many browsers the certificates for common websites are pinned, so if you tried to go to gmail.com for example and a proxy was intercepting it, and was also trusted as a certificate authority, chrome would still prevent the page from loading.
Would it be true to say that HTTPS-over-proxy provides zero security for the end user, since a proxy must be able to encrypt raw HTTP requests/results on behalf of the client? In other words, the proxy can be blatantly malicious against the user, and the client won't even be able to realize that. The only security would be against any third-party eavesdroppers (someone else besides the user, proxy, or final website).
I might be wrong about that too, but I'm trying to grok it.