Kurt Williams has done a very good writeup of things a startup company should considering when choosing development environments. You can read his blog here
I agree with most of what Kurt says but there is one thing that I would mention.
"Sure it's great for rapid Web development. But what about next year when you need to build a GUI?"
I find that a lot of overly complex solutions are designed/built on the basis of this argument. The counter-argument is that doing something in a quick time frame (ala RoR) and only concentrating on what you actually need now, provide immense benefits in time and cost. But more important is that it's hard to forecast your system's longterm needs so why invest time up front on features that may may never materialize? This may sound ignorant but I think that more often than not, we design/plan/develop to support things that we may need but never end up needing it. What's worse is when you've properly accounted for something but the business requirements have changed so much that you end up doing a major rewrite anyways.
For a startup, speed to market is of essence I imagine. Wouldn't it make sense to get your product out as quick as possible and when it takes off or you get that injection of VC, to then go back and revamp it properly?
I'm not a Ruby fan boy but I have been contemplating the choice of development environment for an upcoming project that Kurt's very post addresses.