Except curl | bash definitely executes code by the author controlling the URL you put in, and if the URL is HTTPS, in a reasonably secure fashion.
There is no validation when you winget whether or not the executable is from the official source or that a third party contributor didn't tamper with how it's maintained.
> in a reasonably secure fashion
It's trivial for a remote server to hand two different versions of a script with the traditional `curl | bash` pipeline. https://lukespademan.com/blog/the-dangers-of-curlbash/
There is 0 validation that the script that you are piping into bash is the script that you expect. Even just validating the command by copying and pasting the URL in a browser -- or using curl and piping into more/less is not enough to protect you.
curl | bash is absolutely on my very short list of “things I’ll never do” and I wince when I see it. rm -rf starting from / is another. I watched someone type in (as root) “rm -rf / home/user/folder” once. By the time I realized what had happened it was too late.
If you think HTTPS is performing code validation I have news for you.
HTTPS only guarantees the packets containing the unverified malicious code are not tampered with from the server to you. A server which could very well be compromised and alternate code put in its place.
You are drawing an egregious apples-to-oranges comparison here. Please re-read what you said.
You could serve digitally signed code over plain HTTP and it would be more secure than your example over HTTPS. Unfortunately there are a lot of HTTPS old wives' tales that many misinformed developers believe in.