For instance, this commit https://github.com/postgres/postgres/commit/c64d0cd5ce24a344... that implemented a minimal perfect hash solution to speed up the parser.
The actual Perl code: https://github.com/postgres/postgres/blob/master/src/tools/P...
(I have no idea what’s behind it, but I’m sorry to see Sawyer X leave. And there certainly is cruft in Perl.)
Perl was hugely productive in its day, when alternatives were either non-existent or extremely nascent (Python and Ruby) or things like C, C++, Java, or Bash. You can probably imagine how writing Perl was fun for script-y tasks when compared to doing it in those languages. So, it has a large legacy presence and isn't going anywhere.
Plus there's a few people for whom it is muscle memory, and IME muscle memory can easily beat out language niceness/appropriateness for productivity in personal things.
Disclaimer: I was born in the early 90's so I was learning long division during Perl's glory days. My perspective is mostly from working in a large Perl codebase that was born in those years and talking with the people who chose Perl for said codebase.
Everyone has different tastes in Languages. I’m ok with that.
Today, data is often semi-structured and jq has become part of the toolbox as well.
1) forward symbol references
2) moderate type checking (at both compile and run times)
3) Mojolicious.
Whether it is worth learning both Perl and Python for the same project is questionable, but as for assembling and cleaning up data, I haven't come across anything as good.