A lot of "tools" have a high starting friction for solving some problems. Consider the prospect of "whipping together" a web server log analysis program in Java. Uh, no thanks.

Perl has a delightfully low starting friction. With it we can solve a lot of gnarly little problems quickly, and people like that.

There's a down side to this type of popularity, though it might not surface for a while. If you get the reputation as the guy to go to to get a lot of gnarly little problems solved, you're going to get a long string of gnarly problems. Not only that, but if your environment operations on a "sticky fingers" model of code ownership (i.e., the last person whose fingers touched the code owns it), you could find yourself with a big bag full of ongoing obligations, each waiting to jump up and demand your attention when you'd really rather be spending time on something else.

On way of being the popular "Perl guy" while avoiding the burden of owning all of the little scripts that people depend on is to take the "teach them to fish" approach. Rather than solving people's problems directly, teach them a little more Perl each time, until they can solve problems themselves.

Good teachers can be popular, too.