Is that bad?
It's possible for the server to detect that you're actually using curl (with the help of the user agent of other methods) and also that you're piping it to an interpreter.
Knowing that, the server could send you a malicious payload, that wouldn't be apparent when only downloading the file otherwise.
Some people think this isn't the real issue, that (the lack of) code signing is the real problem. I don't disagree with that, but really, people should look at the code they're going to execute, whenever possible.
And when I say "whenever possible", I sure believe a few lines of shell script deserves to be inspected. Even if you lose the 0.5 seconds of automation the pipe provided. I mean, we're not talking about millions of lines of kernel code, here.
My personal gripe with piping curl output to sh is about expectations. If I have some binary I'm running, I have _some_ expectations about what it will do, same for a Makefile, and RPM, etc. None of those things are guaranteed to do what they're supposed to but I have some idea what _should_ happen.
Unless I read through the script, I have less expectations about what the script is going to do. It says it will install my program but is it going to pull in dependencies from my package manager? Download and compile something, shove binaries in my $PATH, edit dot files in $HOME?
If someone places a shoe box on your doorstep you might expect shoes to be inside. Of course, there's a non zero chance its full of bees. But shoes are a reasonable guess.
If someone places a cardboard box on your doorstep with no writing on it whatsoever, there's no expectation about whats in the box. (Unless you hear the bees buzzing from a distance.)