I'm of the prototyping nature -- for what I work on, it's better to deploy quick, rather than to spend too much time trying to optimize without having any idea of your bottlenecks, or what the user reaction to your product will be.

Perl in general is going to be slower in execution than a compiled script -- but this is taken care of by using FastCGI, or mod_perl (of course, bad code will trip you up if you try to use them). All you're really doing is trading off CPU cycles for memory, though.

Learning a new language, just for a project, is a good way to get your feet wet on a new language, but can dramatically slow down the project (as you try to code as if it's another language, and have to debug, learning how to handle a whole new set of error messages). Sometimes, it's more cost effective to just buy bigger hardware.

Now, if you're going to be connecting to another server as a webservice (SOAP, RPC-XML, etc.), I'd suggest that you find out what toolkits the various sites are using, and try to stick with one of toolkits. I don't care what anyone says about SOAP interoperability, it's a pain in the ass. The soap-builders list was recently discussing what they've termed 'impedence errors' between how the various SOAP toolkits map data types from XML Schema to their underlying languages, which can cause odd interaction issues.

If you're writing both sides of the interface -- write the WSDL first, and make sure you write to the WSDL. It's much harder trying to work the other way round.

And as for those articles you cited -- every benchmark is a point in time measure, given a limited set of constraints. You have problems with people writing programs specifically for the benchmark, which may make them less robust. For instance, the top 500 list uses LINPACK. But your real situation may be more network, memory, or CPU intensive. It's like saying 'shirt A fits better than shirt B' ... you have no idea what size the person who who tested the fit.

So, what's best for your situation? Well, like I said, what's a good fit for me may not be a good fit for you. Come up with a goal (execution time for processes, number of concurrent users, etc.), and work towards it. If you don't meet the goal, you can release it as a proof of concept, even if it's not production, and get user input about the interface, while you work on a new version. Unless your requirements are well defined, I find that the first version tends to be junked most of the time, anyway. It's more important for defining the interface, than it is for the underlying code.