And if you're buying internet service from a rogue ISP that alters web pages, you need a new ISP, not a red X.
Big-name ISPs like AT&T, Verizon, and Comcast have been caught tampering with HTTP traffic to insert their own tracking headers and ads—including scripts in some cases—and not everyone has a great deal of choice in ISPs in their area. This is hardly a theoretical concern, and HTTPS is the most direct and effective way to prevent such tampering.
Your own reputation is at stake, along with users' security. Do you want to get blamed for inappropriate content that some random ISP injected into your page? It may technically be the ISP's fault, or even the user's for choosing that ISP, but you made the tampering possible by failing to take reasonable and customary steps to ensure the integrity of the data delivered from your server.
A security-conscious company, head of household, or even ISP can largely protect users against malware that's been added to sites by detecting it at the firewall, as it enters the network. Unless of course it's https, in which case you can't detect the content at all.
If users want that sort of protection they can manually configure a proxy, thus consenting to allow their traffic to be inspected. We do need better proxy protocols for HTTPS which permit inspection but not tampering, and avoid bypassing the browser's built-in certificate validation. This could be accomplished by making the proxy a simple passive conduit while sharing the client's symmetric encryption key and IV with the proxy. This would let the proxy decrypt the traffic as it's forwarded and cut off the connection in the event of a problem, but tampering would still be detectable since the proxy would not possess the HMAC secret.
Companies and households could force all traffic to pass through the proxy simply by blocking direct connections. ISPs would have a harder time getting away with that, which is as it should be. ISP-level malware protection should be an optional benefit, not a mandatory requirement.