Standardization is, generally, good for maintenance, learning curve and security, not always for retention (fun) though. Too much standardization is like the flip-side of too many one-offs: an extreme that can lead to unintended consequences. It's much easier to accrue technical debt and organizational bifurcation by having too many languages, with a big, painful shake out (technical debt repayment) into just a 2-3 (say Ruby|Python|Node & Go|Scala|Haskell|Erlang|C)... (I've seen this happen at a number of shops go through growing pains at scale).

Overall though, services should expose either a well/self-documented RESTful, zmq or similar API such that they can be rewritten in (your favorite whatever here). Being able to discover the API meta information automagically can be helpful for autogenerating clients.

The other aspect is that services have a risk budget: if the service is conventional and not as crucial, increase the experimentation. If the business/process model is risky/uncertain, use common, stable technologies.

(Gist: Pick from the toolbox, carefully... apply common-sense... Don't get stuck on perfect now or perfect waay later... Anticipate a little now to avoid pain of changing later.)

PS: Enterprise Rails is a great read. It's safe to ignore the Rails bits, because the architecture bits are universal and excellent.

Update: RESTful API metadata formats http://apiux.com/2013/04/09/rest-metadata-formats/ (and also https://en.wikipedia.org/wiki/HATEOAS )