TDD and automated tests arent necessarily exclusive either. Some companies do run automated QA testing to test business logic, but it could be done post development. TDD on the other hand is for producing solid designs and is done from the start, whether or not it leads to successful QA results is another thing.
anyway, to answer the OP. The language you choose should be something you will want to be using in the future, and well into the future at that. Someone mentioned amazon still using perl as a case for perl being a decent platform. I disagree there. Ebay and Amazon are stuck with perl because moving to anything else would be a monstrously expensive exercise, and as the adage goes, if it aint broke, dont fix it. Given that there are better suited frameworks available now, perl or any other older language seems like a poor choice.
for a company that sounds like its about to enter the enterprise market in a middleware capacity id strongly be recommending Java or .NET based solutions. simply because integrating with non web systems will be alot easier when the time comes. Not to mention capacity planning, load balancing, multi instance deployments, application threading, etc. Stuff youre definitely not going to get much exposure to with RoR, perl or even PHP
I’d say the next step for the OP is to hire a consultant that can help guide the development of a product roadmap that extends beyond the next 3 - 6 months. Where are you going to be in a year, 3 years, 5 years. What are your expected technology needs, markets, etc going to be at these time periods?
dont make the mistake of writing the application poorly the first time, and then thinking you can upgrade or rebuild it later. if its for serious business, you will be using your chosen stack for a long time.
personally, the stack i’ve chosen to see my company into the next 5 years of product dev is apache/tomcat app servers, terracotta clusters, spring java framework, hibernate persistence framework and postgres for the data store.
This came after a year of research, lots of phone calls to the product teams and some decent future planning. In five years time, it will be interesting to see if it was a terrible mistake or not to run with this stack.