/usr/bin/env as a shebang - and its security implication

"what if somebody substitutes this executable for their own in say ~/.local/bin ?

Then the script doesn't work for them.

But that doesn't matter, since they could conceivably break the script for themselves in other ways, or run another program directly without messing with PATH or env.

Unless your users have other users' directories in their PATH, or can edit the PATH of other users, there's really no possibility of one user messing another one.

---

However, if it wasn't a shell script, but something that grants additional privilege, such as a setuid wrapper for some program, then things would be different. In that case, it would be necessary to use an absolute path to run the program, place it in a directory the unprivileged users cannot modify, and clean up the environment when starting the program.

As for the difference in behavior between the shell and perl, perl unlike the shell inspects the first line to determine what to run:

$ cat tcl
#!/usr/bin/env tclsh
puts "TCL running as [pid]"
$ perl tcl
TCL running as 39689
$ cat sbcl
#!/opt/local/bin/sbcl --script
(format t "~a running as ~a~%" 'lisp (sb-unix:unix-getpid))
$ perl sbcl
LISP running as 39766
$ 

Uses of this feature include writing tests in some other language besides perl so one can have TAP-compatible scripts in other languages and a prove or whatnot will run them correctly.