Well, just to play devil's advocate, do you read through the source code of MySQL, Apache, or RPM packages every time you install them?
With things like this that come from reputable sources, it's not unreasonable to put some trust in the source and some trust in the smaller percentage of developers who actually read the source code.
As other have pointed out above, the point is not where you think it is coming from, it is where it is actually coming from. Someone could easily man in the middle the connection and change the code you download, so your computer ran whatever they wanted you to run.
You say someone could "easily" man-in-the-middle the connection, but is it really that easy? Or likely? (Assuming you're not installing it from a random public wifi hotspot.)
Even so, assuming you want to be extra careful (you're installing it on a development machine with highly sensitive information), it's not that difficult to clone the repo and edit the install script to install from your local copy of the repo.
I mean yes, it does take a whole minute to verify that the pow code repo is on 37signals' GitHub organization account and that the repo references http://pow.cx.
Although I suppose it is possible that 37signals' GitHub account was hacked and someone maliciously designed a convenient Rack server and website with the intent of targeting the lucrative Rails developer demographic, or that the package the installer downloads is an insidious 37signals trojan not built from the code at the public repo.
This scripts vs binaries situation reminds me of something in the linux kernel: you can't use the sticky bit against scripts. When you add it, it shows as sticky in 'ls -lF' but doesn't work when you go to run it. Sticky bit is only for binaries.
It seems stupid, but on the other hand I never see people abusing the sticky bit, possibly as a result of the higher barrier to entry.
On the other hand, it causes me inconvenience every time I want to do something legitimate with it.
Scripts with interpreters expose a race condition vulnerability whereby an attacker can quickly replace the script with their own before the interpreter, running with higher level privileges, finishes loading.
It is not really a script vs. binary issue so much as protecting against how scripts are loaded.
With things like this that come from reputable sources, it's not unreasonable to put some trust in the source and some trust in the smaller percentage of developers who actually read the source code.