These are arguments why people would want to access the content over a secure encrypted channel, not reasons for the website to force them to; and, in fact, in this frame, it frankly seems like a BAD idea to SILENTLY force them to, as that first request to the http URL is where the game is already lost: an attacker which can do any of the things you are positing wins immediately upon seeing the first http connection attempt, as they 1) now know what website you are accessing and 2) can hijack that request and move you to an entirely different site.
Adding that silent redirect, then, merely looks or feels safer, but, at best, seems more likely to encourage broken behavior among users, who now might always see secure locks in their browser but not realize all of the links they are clicking were insecure and so the chain of trust on their location is now tainted. In contrast, none of the alternatives -- 1) not listening on port 80, 2) replacing the http website with a stub which asks users to manually change the scheme to https, or 3) providing two copies of the website (one that is secure and one that isn't) -- seem anywhere near as dangerous.
(BTW, you are also ascribing magical protection properties to ECH: in addition to the obvious issues with the IP address of a server usually being sufficient to tell what website someone is using, TLS fails to protect users against content fingerprint attacks--think stuff like figuring out what part of Google Maps you are looking at, what video in YouTube you are watching, or even what query you are typing into a search bar"--and so isn't really a sufficient basis for protecting someone against persecution. You need some kind of Internet overlay network to even begin to approach that problem, converting it back into the integrity problem.)
Adding that silent redirect, then, merely looks or feels safer, but, at best, seems more likely to encourage broken behavior among users, who now might always see secure locks in their browser but not realize all of the links they are clicking were insecure and so the chain of trust on their location is now tainted. In contrast, none of the alternatives -- 1) not listening on port 80, 2) replacing the http website with a stub which asks users to manually change the scheme to https, or 3) providing two copies of the website (one that is secure and one that isn't) -- seem anywhere near as dangerous.
(BTW, you are also ascribing magical protection properties to ECH: in addition to the obvious issues with the IP address of a server usually being sufficient to tell what website someone is using, TLS fails to protect users against content fingerprint attacks--think stuff like figuring out what part of Google Maps you are looking at, what video in YouTube you are watching, or even what query you are typing into a search bar"--and so isn't really a sufficient basis for protecting someone against persecution. You need some kind of Internet overlay network to even begin to approach that problem, converting it back into the integrity problem.)