I can understand your use case, but I know a lot of people (often those who use computers infrequently) type out the full URL all the time. They don't know what HTTP or HTTPS is, they don't realise you can omit that part. They just want to access the website.
For those people, it makes sense that typing "http://" would take them to the "https://" site if available. Although they did specify HTTP, it isn't necessarily what they actually wanted.
I think the use case you describe (whilst valid) only applies to a relatively small pool of people. Most people don't really understand HTTP or HTTPS very well. They know it's part of the web address, and some know that "https://" is "secure", but that's about it.
I think it makes sense to direct people to the secure version of the site as much as possible, whilst of course providing a mechanism to switch to the HTTP version if necessary.
If the server says that the thing on port 80 is better served from port 443, then it can issue a 302 permanently move (and a HSTS header to make it stick). If the server offers different content on port 80 and port 443 then the server can do so just fine.
The browser should not try to second guess my explicit instructions.
For those people, it makes sense that typing "http://" would take them to the "https://" site if available. Although they did specify HTTP, it isn't necessarily what they actually wanted.
I think the use case you describe (whilst valid) only applies to a relatively small pool of people. Most people don't really understand HTTP or HTTPS very well. They know it's part of the web address, and some know that "https://" is "secure", but that's about it.
I think it makes sense to direct people to the secure version of the site as much as possible, whilst of course providing a mechanism to switch to the HTTP version if necessary.