1) If you attempt to read the script in your browser first, and everything's great, then go pipe to bash, the server can send alternate content based on your user agent.
2) You'd have a hard time proving the first point, or reviewing to see if a script acted poorly, if you didn't have a local copy, which piping to a shell like this normally prevents you from doing.
If you can't trust the site to give you a safe installer then you can't trust the rest of the sources it gives you either--you would need to audit the entire package. Virtually nobody is going to do that. Singling out the installer as uniquely dangerous is security theater.
I'm having trouble finding a proper source, but I'm pretty sure someone came up with a way to do it even if curl spoofs the user agent. I think it worked by looking for the characteristic timing pattern of bash emptying the pipe in small bursts as it executes the individual script lines.
curl | less
Or copy the request "as curl" from the network tab of any modern browser.
Curlbash lets you change out offerings at will, and leaves no auditable source for the user.
If you execute unsigned code from a 3rd party without sandboxing, transport encrytion doesn't help you much.
Similarly to what happened to e.g. https://transmissionbt.com/keydnap_qa/ or http://www.classicshell.net/forum/viewtopic.php?t=6441
So, why not just install using a package manager that takes some actual security precautions?
The answer is, most of the time, that software developers are either "moving too fast" (docker is guilty of this, but at least they are using the underlying package manager) or more often are just too lazy to provide packages through authenticated channels.
You're trusting the server in this case, not the contents being provided by the server. There's no way to verify that the contents attributed to eridius on github are the same contents that eridius actually put up there.
Github in particular has been shown to have problems with spoofed users.
Let's go one step further. I have a `curl | sh` script for you to execute to install Docker. Just run:
curl -fsSL https://get.docker.com/ | sh
The vulnerabilities go on and on. Using only HTTPS, you have no way to prove that the code you got from get.docker.com is the code that the docker engineers intended for you to use.
`curl | sh` is insecure if you're using an http url, although as has already been said here, it's not really any more insecure than "download this script and run it", unless you're expecting all of your users to actually read through the whole script first. But if you're using an https url then you should be ok since the page cannot be hijacked or modified en route (unless the attacker actually has a trusted certificate for the domain, which is an attack that's way out of scope of this discussion).
The biggest risk with this approach, which the page doesn't even mention, is the danger of the connection being terminated before the whole script is downloaded, as the shell will still evaluate what was sent. But this can be handled in the script by making sure that an early EOF means nothing is actually run (e.g. you can wrap the whole script in a bash function, and then the last line executes the function).
So if you're using an https url, and the script is written to be resilient against early termination, then this is a perfectly reasonable way to install things.