This is more of a tip than a warning. This answer was clearly written when *nix systems were largely multi-user systems. The security reasoning doesn't hold at all on personal computers - in fact I'm going to add "." to my PATH for sure now, hadn't ever considered it. (I'm pretty sure I don't leave malicious executables "lying around" my mac, and if I somehow did that'd be my own dumb fault).
To be more concrete, imagine another user places a malicious script into the file "/tmp/ls". If later someone else wants to look what temporary files are there, typing "cd /tmp" and then "ls", that person would suddenly execute the malicious script without even noticing. This is even worse if that happens to root, which is why this advice is especially important for the root user.
Also, note that for often-used self compiled binaries, $HOME/bin is a good place. On some systems, $HOME/bin is already added to the user's PATH by default, so you just have to create that directory and put your favorite binaries or shell scripts into that.
While the security issues does not seem as high in "modern" environments (mostly single user systems), I think it is still a significant risk because of the surprise factor.
For example, on my mac, there are > 2000 binaries available in my PATH. I cannot possibly know all of them, and if one binary uses another underlying binary I don't know about, it can be quite surprising. I don't think it worths it (using ./ + tab for completion is faster than typing the name of the binary anyway)
A lot of the classic Unix security advice is pretty outdated. For example the idea that someone getting "root" access is worse than someone gaining "ssp" access. Everything interesting is already readable and writable by ssp. The only new thing root can do is destroy stuff that can pretty easily be recreated.
The root account is still useful to prevent ssp from accidentally screwing things up, but as a security measure it's pointless in many cases.
