Valid point; my counter to that would be that if you've got PATH changing randomly and/or unintentionally for production execution environments then you've got an equally large problem.

The issue with hardcoding links is that you can't then change the referenced name without altering which perl you get for everything running against the same filesystem usting that name. You also can't trivially test the same copy of script X (especially if it's called via system down n levels deep by several other scripts so you can't easily prefix the call with /my/other/perl X ...) under a different perl without then editing the shebang for script X. And now everyone running that same copy is going to have to run under that different perl; so you really need to make a different copy and you're back to playing games with PATH to have just that tweaked version found first.

Granted with containers these days it's much easier to get an identical-but-for environment whipped up (in which case it's trivial to go with either approach; depend on PATH or depend on the shebang but you're in a one-off superchroot that can't see anything wrong because there's nothing else on the same "box" for it to see wrong). Pick the approach that works best for you and be aware of the constraints your chosen approach has (hardcoded shebangs means editing and creating a separate copy of scripts to test, whereas PATH lets you change without editing but makes you sensitive to environmental changes).

Edit: I was otherwise distracted when replying and glossed over the alias bit mentioned below; that's an interesting approach.

The issue with hardcoding links is that you can't then change the referenced name without altering which perl you get for everything running against the same filesystem usting that name.

That's why I recommended per-project aliases.