> Enabling HTTPS redirect means the fallback is no longer working, and if the browser doesn't let you in, you basically lost access to information even though it is still right there, just inaccessible.
This is the equivalent of saying that "since phantom issues with preflight checks on airplanes can sometimes result in cascading delays of flights on an entire airport therefore we should get rid of preflight checks on commercial airliners".
In this case people can freely use the HTTPS version. What we argue is stop doing automatic redirects effectively rendering the whole content inaccessible in case of certificate issues - and this a massive problem, affecting much more websites than hijacking traffic by some ISP some years ago. And you can be sure ISPs will be doing less of it as most sites are on HTTPS now. What we are asking is not to kill plain old HTTP for those who want and need to use it.
It's not. ISPs have injected ads. It also gives slightly less data to for ISPs to track since they only get the SNI header (domain name), not what articles you visited.
You could argue that ISPs shouldn't do that, and I'd agree, but unfortunately many people don't have a choice of ISP and some ISPs are shitty.
I hear this argument again and again. You need to understand it's completely useless for websites where you are a passive consumer (i.e. you don't enter any information, just read articles and so on). And, frankly speaking, MITM attacks on passive websites are much rarer than errors related to outdated (and sometimes misconfigured) certificates. Enabling HTTPS redirect means the fallback is no longer working, and if the browser doesn't let you in, you basically lost access to information even though it is still right there, just inaccessible.[0]
[0] Yes, website owners should configure their certificates properly, the process is now very easy, you can add certbot to crontab and forget - but it turns out in real life it doesn't work like this.