(Which isn't to say that I disagree with the security concerns raised of a curl|sh. Just that of course many people don't vet their various source code/shell scripts/executables. None the less, you should give them the opportunity to - a tarball and a detached signature seems to be a pretty friendly approach)
This case is where you know what's at the URL you specified, but since it was/will be downloaded over HTTP, in principle a MITM could change the content when it's downloaded by curl, so you're running a different script than the one you reviewed/uploaded.
Unless of course it's some sort of "timing attack" (advance apology to purists if I'm using this term incorrectly) and the server knows you've downloaded this once (with gosh perhaps) and then sends you the malignant stuff the second or subsequent times.
Edit: sorry, the above makes no sense because you will have reviewed it with gosh and probably wouldn't download it again.
There are lots of ways you can get bad data from a given server over curl, even if using HTTPS and the attacker does not have full control over the server:
* Typo in URL and typosquatter sends you whatever commands they want
* XSS in server-side scripts leads to injection of commands via unescaped tags
There may be others I haven't thought of. Perhaps a DNS glue record can be used to inject shell metacharacters where the server has an error handler that reports the client hostname? The fact that any of these are even possible shows how fragile this mechanism is.