I start from the position that there is no answer to such simplifications of projects. No language is always the best tool (and, by extension, any advocacy that always pushes a certain language for all situations just shows everyone that it's just hype instead of valuable advice).

The thoughtful planner should also note that using Perl doesn't automatically come with savings in developer time. If you're somewhere that already has a big investment in another language, good libraries to do the things you need, and good programmers who truly know that language, you probably will be able to develop faster in that language. Starting from scratch in Perl can have a lot of ramp up time, and if you are new to Perl you're going to spend a lot of time just figuring out how to do all the things the monks take for granted.

Even bringing a good Perl programmer into a non-Perl shop can be especially slow. There may be long term benefits, but in the short term development will not necessarily be that fast. It really depends on the particular developer and the work environment.

The last big code review I did optimized for developer time and lost so poorly on execution time and memory that it ended up killing them later. They switched to Java, which I think was a good thing for them considering their in-house skill sets. Perl will let a less-than-good programmer get something going quickly, but without a more-than-good programmer you may have to pay for that later.

So, the question of "Why should I use Perl?" almost answers it for you: if you don't know the trade-offs involved and you don't know what's more important to you, any answer is pretty much worthless because it's just a guess.