ISPs used to do that more commonly before HTTPS killed it but it's an expensive service to operate: very high traffic and if anything goes wrong your customers have a bad experience on the entire internet. The only way to do it is by intercepting TCP connections to port 80 so that system has to be as close to 100% uptime as you can manage.

Site owners generally hated it, too, since tampering proxies were a perennial source of compatibility bugs and protocol violations even before you had things like the ones which tried to “optimize” images by recompressing them, giving everyone on that ISP a bad experience which you don't know about. Stack Exchange has a number of threads where someone was trying to figure out why only some customers had complained months-stale content (Hi, Telemundo!), low-quality images (Hi again, Telemundo!), mismatched languages or truncated/corrupted contents, etc.

Yes, SSL.

That makes me wonder... I wonder if there is a process by which providers would sign certs to individual ISPs and providers to let them intercept low/medium security content like streaming.

Like, if Netflix is going to serve streams over TLS for philosophical/privacy-from-government/privacy-from-wifi reasons, but wants to lets ISPs cache data, they could create a certificate for each ISP/organization and provide the keys to that org.

Then, if NF can identify you are coming from a particular ISP, they can have your content served from the ISP's netflix subdomain, and the ISP could intercept/cache/re-encrypt the data.

Just a thought.

Many ISPs do exactly this for high traffic content that is not served via TLS (which prevents it as you suspected)

SSL is exactly the problem. Has pretty much killed caching proxies.