There are other risks besides malicious webservers. Even an accidental network glitch can be fatal, for example if the connection is dropped after the first "/" here:
curl won't buffer the entire stream, since that would be silly, so if it is a big enough response then curl will have already passed parts of it along to the shell through the pipe.
Is this likely to cause a catastrophic failure? No. Is it possible? Absolutely.
When curl gets the end of the input, it exits and the shell closes the pipe generating an EOF. You get a broken pipe writing to one if the reader goes away, not reading from it.
I verified this on OS X with the below "server":
$ stty -icanon min 1 time 0
$ nc -v -l 6666
GET / HTTP/1.1
User-Agent: curl/7.34.0
Host: 127.0.0.1:6666
Accept: */*
HTTP/1.0 200 ok
Content-Length: 1000
echo foo
echo bar^C
(^C is a control-C). Even with an explicit content-length so curl knows the response was truncated, and without a terminating newline, the shell executes both commands.
Again, quite unlikely to be a problem in real life. But it is still a bad habit to feed curl into sh directly.