From a penetration standpoint, my first point of attack on a system is the PATH variable. It enables me to leave a similarly named script file masquerading as a system binary in an executable directory that I have write access to.
Theoretically correct. In practice, anyone who has write access to /usr/local/bin and /usr/local/sbin has likely root-like powers, and therefore can also modify /usr/bin and /usr/sbin. I know that theoretically they could be protected differently, but that would be very unusual.
From my own experience, my preference is to NEVER RELY ON THE PATH VARIABLE to be true. Always hard code full path names for binaries into your scripts including the start up scripts.
Good advice. Or make the scripts self-contained: Right at the beginning, set the path what it should be, then rely on it. But the problem with this technique is that you have now introduced coupling, between where files are stored and the scripts that use them. So from now on, when you change one side, you have to update the other.
Symlinks are far safer than the PATH.
Except that you have to store your symlinks in places like /usr/bin, which programs like freebsd-update think they have freedom to modify during upgrades. So after every upgrade you have to recheck the links.
By the way, as much as I point out the problems with this approach, I use it too. For example, to make life easier, I have Python programs that can be used on multiple platforms. But the python executable is stored in different places on different platforms, yet I need to know its location in the shebang line of the script. So I now have the convention that on every machine that I control (and where these scripts need to run), I will have /usr/local/bin/python3, which can be a soft link, or the real exucutable, but it will work.