You say they can guess what you're looking at with HTTPS.. well if you use SRI without HTTPS, then they don't need to guess.. they absolutely know what you're looking at.
Also, if they can change the page (which they can if it's over http), they can change the hash as well.
Also, SRI is like 9 months old since the first draft... which means it does nothing for the visitor unless they are using the newest version of one of the major browsers.
Unless my understanding of SRI is totally wrong, it is to protect against malicious changes to third-party resources, usually by the hosts of those resources (or someone attacking them) or a poisoned cache thereof, not to guard against MITM.
For example, example.com (delivered over HTTPS) could use jquery, and include in the page it delivers to you both the URL and a hash of the jquery scripts; you could then fetch those scripts over untrusted channels or from untrusted servers, and be sure that they are the ones that the administrators of example.com intended to reference. If example.com were not using HTTPS at all, then they could just be the resources that the Man In The Middle of your channel to example.com intended you to see.
And I think, of the browsers that do support SRI (possibly in prerelease versions or behind feature flags), they require the page to be delivered over SSL anyway.
Take a look at that HTTPS certificate that you think means you're talking to the site of your choice. If it says "cloudflare.com", "incapsula.com", "edgecastcdn.com", "palmwebservices.com", "cdnetworks.net", there is a man in the middle of your HTTPS connection. This is the case for at least 38,000 sites we know about. There are probably more. (The list: http://john-nagle.github.io/certscan/whoamitalkingto04.pdf)
HTTPS Everywhere was well-intentioned, but the people behind it didn't realize that high-volume use of HTTPS forced less secure use of HTTPS. That's why it's a form of security theater.
I still trust the link between CloudFlare and Hacker News more than I trust the link between a dodgy ISP and Hacker News. Further, there's no reason that a CDN can't use SSL to the backend, so in that case the only weak point is the CDN and the original site, not any of the links.
Using HTTPS to a CDN is still far better than using HTTP to a CDN or to the original site.
Nothing forces sites to use a CDN. HTTPS, by itself, does not massively increase load. If the limiting factor of your web server is how fast you can do cryptographic operations for HTTPS, you're doing rather well; most of the time that won't be your limiting factor.
Using a CDN is not wildly less secure than using a hosting service, and numerous sites use hosting services. "Secure to the CDN" is still a net improvement over "completely insecure".
By all means, complain about sites using a CDN that you don't trust. That's not an argument against universal adoption of HTTPS, though.
HTTPS does not break caches; that's FUD. Browsers can cache
HTTPS pages just fine
Proxies are not a common setup; approximately zero home users use them, and a subset of corporate networks do (only the obnoxious ones).
In any case, caching proxies are far less important than caching browsers, and HTTPS does not in any way break caching browsers.
Even with CDN terminating SSL, it protects you from injected malware and ADs between you and the CDN by your ISP.
If you want to work on a spec to make cacheable, signed hypertext documents, I will be totally down for helping. But no such spec exists today.
Subresource integrity can protect against changes done on the server, while TLS can protect against changes done by a man-in-the-middle. They protect against different things, and do not significantly overlap.