The title is intentionally provocative. This is not really a post about Perl--though I do think Perl usually is the right tool (at least for me). It is about the general philosophy of picking a language for a project and learning new languages.
I sometimes spend days before starting a new project agonizing over what language I should use. I often create elaborate text files comparing the features, libraries, and ecosystems of several different languages as they relate to the project. I want the right tool for the job.
After all that, I usually end up going with Perl. Perl is my favorite programming language. It's what I'm most familiar with. In most cases, Perl is the right tool.
You may have a different language that you're most experienced with. In that case, chances are the right tool is [insert language here]. Insert your preferred programming language.
I wrote my own CMS for my website...from scratch. I'm wise enough now not to try that again, but it was a rite of passage (plus, before that, my website had been completely hand-coded HTML).
Perl provided me my first paying developer position as a student worker my freshman year in college (albeit, as a student worker, it was minimum wage and limited to ten hours per week). Students scanned their ID cards as they entered and left the weekly chapel service. A certain number of chapels were required each semester. At that time, the card scans were saved to a text file on a network drive. I wrote a Perl script that processed the files, stored the data in a SQL Server database, and created a web interface that allowed the dean to run reports on how many chapels students had attended and enabled students to view how many more chapels they needed to attend to meet the requirement for the semester. After coding the CMS for my personal website with nothing but CGI.pm, I was wise enough to pick CGI::Application for this project. (Today I usually use Mojolicious whenever I need to create a web app or web interface.)
Today I work at that same university as a DBA. Recently a co-worker dug up a copy of that web app I wrote as a freshman (thankfully the university has since moved off that homegrown solution to an off-the-shelf solution). I was appalled at the code. Both Perl and I have changed a lot in fifteen years. Even as a DBA, Perl is still the tool in my tool chest I most often turn to. Most of the tasks I need to solve involve getting data out of (or into) a database, formatting it (usually as CSV or XML), and sometimes using an API or SFTP to integrate it with a third party. Those are the kind of tasks Perl excels at. CPAN has DBI, Text::CSV, and Net::LDAP.
If my app needs to query a relational database, I'm going to use SQL. I've tried a couple different ORMs, and maybe I'm biased because I'm a DBA, but I always find working with SQL directly to be a better experience. I think what a lot of developers are trying to avoid with ORMs is mixing SQL and Perl. I agree that's ugly. I keep my SQL in separate files and load it with Template::Toolkit. Treating my SQL as templates, I'm able to do a lot more than I could with just bind variables.
While SQL is the right tool for querying databases, most database vendors have extended SQL to turn it into a Turing complete, general-purpose programming language. In the case of Oracle (the database at work), that is PL/SQL. I know I'm a DBA, but I find PL/SQL particularly unpleasant. It is very verbose. What I could do in a few lines of Perl takes me tens of lines of PL/SQL. We have an emergency notification service we use to send texts to all students and employees in the case of an emergency. On a regular basis, we need to export mobile phone numbers from our database, format them in a particular format, and transfer them using WebDAV to the service. My predecessor had implemented this as a stored procedure written in PL/SQL. We had need to make some changes to the output format. I decided to rewrite it in Perl, and I haven't regretted my decision for a second.
I also know a co-worker who did the opposite. We recently hired a new analyst. The analyst he replaced had a lot of Perl scripts to automate formatting files and such. The new analyst is rewriting most of these in PowerShell. Even though I think Perl excels at automation and formatting files, PowerShell is probably the right tool for him, because he is more familiar with PowerShell. I tried to convince the co-worker of the benefits of learning Perl, but ultimately I wasn't successful.
I like to tinker with the Arduino. I can use other languages on the Arduino, but because of the ease of use of the Arduino IDE, chances are the right tool is the Arduino language.
I haven't done any mobile app development yet, but I would like to develop a mobile app someday (even if just for fun). In that case, the right tool is often dictated by what is supported by the mobile platform you're targeting. If I want to write an Android app, I could choose Kotlin. For an iOS app, Swift is probably the right tool. I could also choose a cross-platform framework such as LambdaNative, Flutter, or React Native.
Most of the time performance is not really that big of a factor in choosing the right tool. Developer productivity often outweighs shaving off a few milliseconds of processing time. For most applications, whatever language you're most familiar with is probably fast enough. There are exceptions though.
I know Electron is everyone's favorite punching bag right now, so I hate to heap on more criticism, but it's mostly deserved. I've tried using VS Code. It is attractive and has some cool features, but it's also slow as molasses. If I have a few tabs open (say a Perl script, HTML document, and CSS style sheet), it takes several seconds when switching between tabs. My workstation is a Core 2 Duo with 8 GB of RAM. I know, I know, Moore's law and all that, but I shouldn't be forced to upgrade my computer just to use a text editor. It's not like I'm trying to play a realistic 3D game. Maybe you have an app you wrote with Electron and it is simple enough that it performs well even on older systems. Good for you. Then Electron probably is the right tool for you. But I would say that Electron was the wrong tool for VS Code (not that me saying that really matters).
I'm working on a project where I'm writing a FUSE file system to mount a cloud service. My first thought was that something like a FUSE file system might be one job where my beloved Perl might not be the right tool. For performance reasons, I thought I would need to write it in a compiled language like C or Rust. Then I came across an article about writing a network file system in Python, and that any latency from the network outweighed choosing Python. Sure enough there was a CPAN module with FUSE bindings. I did some tests, and Perl was more than fast enough. I should have never doubted.
I also write scripts in Bash and AWK. For simple system administration tasks, they are the right tools.
I have an ever growing list of programming languages I would like to learn someday. Lately dependent types have caught my interest, and I would like to learn Agda (or maybe I should learn Idris instead). Rust seems to be the latest hotness, and I would like to learn a compiled language. I've wanted to learn Ruby almost since I first learned to program, but I've never got around to it.
After I had known Perl for several years, probably inspired by one of those many learn a new programming language blog posts, I decided to expand my horizons. I had heard all kinds of wonderful things about functional programming, so I wanted to learn a functional language. I considered Haskell, but I had a friend who had actually majored in computer science (I majored in religion and have never taken a computer science or programming class) that a class on Haskell had been one of his most difficult classes, so I sought out a more gentle introduction to the world of functional programming. I was drawn to Lisp and finally decided upon (for reasons I no longer remember) the Scheme dialect.
I'm also comfortable with HTML, CSS, SQL, Bash, AWK, YAML, JSON, and the list probably goes on. I take these as a given though. They are necessary tools that go along with being a developer. I guess if you're an embedded software engineer who only ever writes C for embedded systems, you may not know HTML and CSS. If you're a Windows developer, maybe you don't need Bash (but I assume you do know some equivalent like PowerShell).
If two programming languages use two different paradigms (say, object-oriented and functional), they may be more different than two languages of the same paradigm. That's why it's useful to learn at least one language from each paradigm, but even a C++ hacker shouldn't have too much trouble figuring out Haskell or OCaml source.
I've fixed bugs in or made minor modifications to programs written in C, COBOL (yes, parts of our ERP are still written in COBOL), Java, PHP, Python, and Ruby (and maybe a few more I've forgotten about). I don't consider any of these languages that I know. I was able to use my knowledge of programming in general to browse the source code, identify the relevant area of the code, look up any unfamiliar keywords or syntax in that area, and then make the needed change.
The university I work for recently changed the LMS we use. The analyst who supports the LMS could export grades to a CSV from the previous LMS that he could then import into our ERP. The new LMS doesn't have a feature to export grades manually. Instead you can configure an HTTPS endpoint that it publishes grades in CSV format to. The documentation gave an example PHP script that would take grades published to the endpoint and save them to a text file. We could, of course, have written our own endpoint in Perl, Ruby, Python, etc., but to save time we used the example from the documentation. I don't know PHP, but I was able to look up just enough info about the keywords in the example to make a few small modifications to it. (Now the analyst has requested a few more modifications, and I am seriously considering rewriting it in Perl to make it easier for me to maintain.)
We also recently switched from a proprietary COBOL compiler to GnuCOBOL to save money. Our ERP vendor only officially supports the proprietary compiler. We have an analyst who is old enough that he actually started out programming COBOL. His help (and reading the Wikipedia article on COBOL) was enough to make the few changes I needed to get the COBOL to compile with GnuCOBOL. I actually modified the Makefile (another language itself) to use sed to modify the COBOL right before compiling it. This way upgrades to our ERP won't overwrite our customizations to the COBOL.
I've also read the introductory tutorial on the websites of several languages I'm interested in and sometimes went on to solve a few Project Euler problems with the language. I don't consider those languages I know. I don't consider myself knowing the language until I've actually built something with it (and, no, a few Project Euler problems don't count).
I completed the interactive tour on the Go website. I didn't like the Go language (I felt like it was telling me what to do), but I think that tour should be the gold standard for language tutorials. Every language should have an interactive tutorial on their website like that one.
I took the Go tour when I was thinking I would need to write the FUSE file system I mentioned above in a compiled language. It was disheartening. For me, programming is something I enjoy. Yes, I program for work, but I also program for fun on my own time. I enjoy programming in Perl. Go just didn't seem fun. If I used Go for the project, I feared I might not enjoy it.
I think that is one thing holding me back from learning more languages. What if I invest all this time into learning a new language, but then I don't enjoy the language?
I may also love the language and never find out if I don't give it a try. I learned Scheme after I had several years of Perl under my belt. I like Scheme a lot. I don't use it as much as I use Perl. The main reason is libraries. There is a CPAN module for almost anything I need. Even Racket with its batteries included philosophy and a package repository doesn't come close to what's available on CPAN.
I learned Scheme in 2011 (at least that's the date of my first commit of Scheme code on GitHub). If I don't want my average of a new language every seven years to slip, I better get to learning my next language. I want to create a ray tracer using Ray Tracing in One Weekend. Maybe I'll write it in Rust. Or OCaml. Oh no, I feel days of research and detailed text files coming on. Maybe I'll end up doing it in Perl.