1. Developer Productivity - A save and reload framework might be more suitable if that is the existing mindset in your group. This seems to be a very underrated factor while judging your framework/dev set-up.
2. Existing codebase's dependencies - If you have a lot of dependencies which cannot be easily replaced in your new language, that is going to be a problem.
3. Performance of the framework - You want to have at least one large software shop using the framework whom you can use as a guide.
4. Community - This comes down to not just library support for future use cases; the rule of thumb is, if the first few setup issues you are having are easily solved by answers from StackOverflow, you are probably OK.
5. Recruitment - Languages/Frameworks often define the culture of a workplace and directly affect your recruitment base.
Actual Suggestions - 1. Scala/Play - Can use existing Java libraries. Encourages a less verbose coding style than is typical for Java. Twitter moved their Rails circus to Scala. A big con - their language bumps are apparently frequently non backwards compatible. So you might have to hold for a bit until things stabilize.
2. Rails - Easy setup. Solid Community. Good testing framework. Cons - Proven to not scale at Twitter. There are at least two other examples of Rails not scaling. Why jump ship twice eh? Dynamic typing is not exactly helpful when your code reaches a certain LoC count.
3. Golang - Good concurrency model. Easy to read code, almost a C-with-concurrency. Backed by Google; this is not going to be abandoned because a lot of internal Google teams are deeply invested in Go. Cons - Not as popular yet as Scala or Rails, so lesser library support; but rapidly expanding community.
ThoughtWorks has a languages and frameworks radar that can serve as a good 10,000 feet survey of the field - http://www.thoughtworks.com/ra... . In an ideal world, do not get too invested in any one framework.
The problems with perl - (I work in a large perl shop, if not the largest perl shop.)
Recruiting is a pain.
New devs need to get comfortable with perl idioms; a pattern that seems to encourage code obfuscation more than readability.
Optimal runtime concurrency is impossible. Even if you roll our own Futures library.
Bless is not safe. Consequently, you lose any sort of concrete interfaces.
There is no concept of unit testing.