This has a host of problems for https websites:

- The request is susceptible to a man-in-the-middle attack.

- Cookies are sent in the clear unless declared secure when set.

- Have to operate an http endpoint and redirect users to https = more devops and user visible delay.

Yes, the operator should ideally add an HSTS header and get included in the preload list [1], but that adds to the already long list of headaches.

It's time browsers just default to https, and if the connection fails (= name resolves but can't connect on 443) fall back on http.

For sites that cannot or will not switch to https, they can add a to-be-speficied NO-HSTS header to https redirect proxies and get added to an exclusion list (which defaults to localhost).

Yes, this is somewhat aggressive, but with suitable fallback existing sites should still work (with a minor performance penalty) while the vast majority of websites that run with HTTPS but without HSTS all get protected + sped up in one fell swoop.

[1] https://hstspreload.org/