I want them to not use a one-liner. Step-by-step:
1. Download the files
2. Download the public key
2a. verify the public key if you've never seen it before (publish in the blockchain, have lots of high profile technologists sign it, etc)
3. If the verification matches, then proceed.
Teaching developers to value "clever one-liner hack" over "secure, dependable solution" will lead to bad habits.
1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't:
2. Run curl https://install.meteor.com|sh
It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).
There is no reason you couldn't automate your whole suggestion, except for that one, which makes it infeasible and open to all manner of social engineering.
But the problem is anyone compromising the site can just change the line from "blahblahblahblahbalhMETEOR.COMkey" to "attackerchangedblahblahblahblahbalhMETEOR.COMkey" right on the web page, and people will copy the one verified against the wrong key. So that doesn't work.
Nor do clients have caches of PGP signatures, nor is there some totally obvious third-party that you can verify it with. You can't just go:
curl|{check_if_signed_with_www.this-site.com}|sh (which would pass visual inspection - the attacker would have to change www.this-site.com to something else) because there is no obvious mechanism to do that. Who will tell you whether https://install.meteor.com/ has signed it?
Well, HTTPS will kind of tell you. So "https://install.meteor.com/" is a lot better than nothing...
If you're going to entertain the idea of the HTTPS site being compromised to serve whatever they want, well, there is precious little you can do about it.