The web uses port 443 for HTTPS, so this example is unlikely to be an issue. Having said that, there are weird and wonderful corporate and government proxy configurations out there that do wacky things.

My guess is that their entire system is so tightly coupled that they can't unpick this without a huge amount of work that requires real developers to stick with it and get around it.

Adding HTTPS support doesn't necessarily mean removing HTTP.

Even if there was an ancient service that can't handle HTTP, keeping HTTP and adding HTTPS support will do just fine.

You're just making up things trying to find a reason. HTTP was only invented in 1989, so these imaginary early 80s clients likely don't exist

Good example, but even so I can think of many way a well directed intern could solve that without touching the code of that things.

“Do not redirect from HTTP to HTTPS if source is IP is in list if legacy devices.”

There. I’ve solved it.

Similarly, a filter based on User Agent would likely also work.

I meant actually solve it by upgrading to HTTPS in a reverse proxy but yeah :)

They're already behind Akamai, and have a valid certificate and the site is reachable on HTTPS... but redirects back to HTTP.

That's purposeful incompetence, not an accident, oversight, lack of budget, or anything else that can be excused.

There is no sensible reason, except perhaps money. And using it as an attempt to increase funds or raise the low pay levels hasn't worked and won't work. It is likely to be stuck that way until Chrome stops serving plain HTTP at all from the Internet and someone gets a kick in the bum to fix it, after which a few clicks with Cloudflare or other HTTPS front end provider will sort the problem. And possibly even save money due to caching and not passing on much bad traffic.