I've written elsewhere about not messing with the provided-by-the-OS Perl. And I was not advocating messing with it here.

There are dozens of systems I work with. Most of them have a /usr/bin and most of them have Perl. I don't believe there is a single system that I've worked with recently that has Perl and has /usr/bin that doesn't have a /usr/bin/perl. Tons of systems I work with don't have a /usr/local/bin/perl. So, if I'm going to put a path to Perl in a #! line of something that isn't destined for a specific system (or specific group of systems), then I'm going to use /usr/bin/perl as that path.

My preference would be for modern Unix kernels to handle a simple #!perl as "find 'perl' in $PATH and run that". But I have yet to see a kernel that supports such. I've seen people do "#!/usr/bin/env perl" but I've also seen systems that have /bin/env and don't have /usr/bin/env. And it seems both like hackish and imprecise thing to do.

I have a lot of little utilities that don't make many demands of Perl and those, even when I put such on a specific system, I usually leave them pointed at /usr/bin/perl and I don't recall ever having a problem with that.

I work with a lot of large-scale systems of Perl code. Each of those have a version of Perl dedicated to them (along with a stable of specific versions of specific Perl modules). So those versions usually don't end up as /usr/local/bin/perl since sometimes you end up with two different subsystems running on the same box and they might not depend on the same build of Perl. But I also don't post such things to the public.

So my preference is for public postings of Perl scripts to start with #!/usr/bin/perl. I actually use Perl scripts even on systems that don't have a dedicated "for some application" version of Perl installed on them.

But it isn't a terribly strong preference. My expectation is that the #! line will often have to be eventually modified. But I'd rather start with a #! that is most likely to at least be present on most systems.