The $HOME/bin, . and ./bin are usually looked as a security risk.
for the $HOME/bin its the problem of some "cracker" push some script (say a script named nano) to there and waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever, the command isnt important, its the payload it can execute)
for . and ./bin is still the same problem, added a extra: working on the wrong directory.
If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), its because they do different things... what if you run the incorrect one?
If you name your commands the same way (lets call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (specially if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).
It might look a innocent mistake, but they happen everyday to many people! :)
a good workaround (or better solution) is to use alias:
and add on the script the correct cd to make sure it runs on the correct directory.
This way play with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone crack your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.
but hey, its a personal choice, you are the one that knows what are your local risks and what the commands do.