Standardizing a Release/Tools group on a specific language
First, it's important to note that it is very hard to convince someone they're wrong.

He's advocating bash scripts and Perl,
  due to their universality and
  simplicity

Bash scripts are not simple.  The bash programming model is really complex and unfriendly.  if statements and expressions, in particular are horrifying.
Perl may or may not be simple.  
Bash is universal.  Perl, however, is exactly as universal as Python.  Python is pre-installed in almost all Linux distributions.  So that argument is specious.
The "universality" of bash, Perl and python is exactly the same.  The "simplicity", however, is not the same.  You won't find it easy to to "prove" or "convince" anyone of this once they've already pronounced Perl as simple.
The Situation.
If the boss is advocating Perl, and Perl is not the answer, you will find it is very hard to convince someone they're wrong, making this effort nearly impossible.
If the boss was just throwing out ideas, then this is just difficult.
Quick Hack.
An easy thing you can do is to attempt head-to-head comparisons of Python and Perl for some randomly-chosen jobs.  You can then have a code walkthrough to demonstrate the relative opacity of Perl compared with the relative clarity of Python.
Even this is fraught with terrible dangers.

Some folks really think code golf is important.  Python loses at code golf.  Perl wins.  There's nothing worse than "Angry Co-worker with Perl Bias" who will kill you with code-golf solutions that -- because they're smaller -- can baffle management into thinking that they're clearer or "better" on some arbitrary scale.
Some folks really think explicit is "wordy" and bad.  Python often loses because the assumptions are stated as actual parameter values.  Some folks can (and do) complain at having to actually write things down.  Read Stack Overflow for all of the Python questions where someone wants to make the try: block go away in a puff of assumptions.

If you choose random problems, you may -- accidentally -- chose something for which there's an existing piece of Perl or Python that can be downloaded and installed.  A language can win just through an accident of the draw.  Rather than a more in-depth comparison of language features.
Best Bet
The best you can do is the following.

Identify what folks value.  You can call these "non-functional" requirements.  These are quality factors.  What are the foundational, core principles?  Open, Accessible, Transferrable Skills, Simplicity, Cleanliness, Honesty, Integrity, Thriftiness, Reverence, Patience, Hard Work, A Sense of Perspective, Reef the Main in Winds over 20 kn, etc.  This is hard.  No sympathy here.
Identify the technical use cases.  These are "functional" requirements.  Which bits of glue and integration there are?  This is hard, also.  Requirements erupt of out of the woodwork when you do this.  Also, when you have a Perl bigot on the team, numerous non-functional requirements will pile into this area.  Your manager -- who proposed Perl -- may be the Perl bigot, and the use cases may be difficult to collect in the presence of a Perl bigot.
Identify how (a) Perl + Bash vs. (b) Python vs. (c) Java fit this core values and the functional requirements.  Note that using Python means you do not need to use Bash as much.  My preference, BTW, is to pare Bash down to the rock-bottom minimum.

This is a big, difficult job.  It's hard to short-cut. If you find that Perl is not the answer and the Perl bigot you need to  convince is the manager who proposed Perl in the first place, you may find that convincing someone that they're wrong is very hard.  
Edit.  I am aware that I am forbidden from using the string "Perl Bigot" to describe the manager's potential level of bias toward Perl.   I, however, insist on using "Perl Bigot" to describe the manager who proposed Perl.  The question provides no information on which to change this.  The worst case is that (a) the manager is the Perl Bigot and (b) Perl is not the answer.
I'm part of a six-member build and release team for an embedded software company. We also support a lot of developer tools, such as Atlassian's Fisheye, Jira, etc., Perforce, Bugzilla, AnthillPro, and a couple of homebrew tools (like my Django release notes generator).
Most of the time, our team just writes little plugins for larger apps (ex: customize workflows in Anthill), long-term utility scripts (package up a release for QA), or things like Perforce triggers (don't let people check into a specific branch unless their change description includes a bug number; authenticate against Active Directory instead of Perforce's internal passwords). That's about the scale of our problems, although we sometimes tackle something slightly more sizable.
My boss, who is reasonably technical, has asked us to standardize on one or two languages so we can more easily substitute for each other. He's advocating bash scripts and Perl, due to their universality and simplicity. I can see his point--we mostly do "glue", so why not use "glue" languages rather than saddle ourselves with something designed for much larger projects? Since some of the tools we work with are Java-based, we do need to use something that speaks JVM sometimes. (The path of least resistance for these projects is BeanShell and Groovy.) I feel a tremendous itch toward language advocacy, but I'm trying to avoid saying "We should use Python 'cause I like it and Perl is gross."
Instead, I'm trying to come up with a good approach to defining our problem set: what problems do we solve with scripts? Would we benefit from a library of common functions by our team, or are most of our projects more isolated? What is it reasonable to expect my co-workers to learn? What languages give us the most ease of development and ease of modification?
Can you folks suggest some useful ways to approach this problem, both for my own thinking process and to help me facilitate some brainstorming among my coworkers?