Yes, but any application running under the same UID can get the secret token -- or it can be grabbed from whatever file sets up the environment. This isn't necessarily an improvement in security and is probably a step backwards. It's more helpful to make sure you don't allow secret_token.rb into the repo than it is to make sure the token gets loaded from the environment.
Yes, but only marginally; You can get the environment of another process with the "ps" command trivially. If you're in a shared environment you just made it that much easier for other people to monkey with your stuff.
The common wisdom seems to be that you can forget about security in a shared environment regardless. The "secret key in environment variable" technique is mostly useful at protecting against malicious employees since it's easy to limit access to the production server but not so easy to limit access to configuration files which are in a Git repository.
While I generally agree, there's a lot of shared environment out there that people seem to think is secure. I also would posit that its probably easier to get the calling environment through some flaw in bad programming vs getting a file off the filesystem. I would also posit that not having strong controls on your source tree is probably not a good thing as well...
The only secure shared environments I would trust are jailed environments or virtualized OSes, and even then only if I could control the hardware. Even then there have been vulnerabilities which allow virtualized OSes to access the host system (and "sideways" into other OSes), meaning even something like EC2 is potentially vulnerable.