There are inherent dangers in just about everything you do on your machine... it's partly a matter of trust and risk management.
Theoretically, since you've given preference to /usr/local/bin over /usr/bin then any binary in /usr/local/bin is going to have priority. If some malicious software gets installed in /usr/local/bin then you could be in trouble. This includes all the standard build tools (/usr/bin/make, /usr/bin/gcc, /usr/bin/autoconf, any of which could compromise building applications on your machine) and even things like /usr/bin/ssh which could compromise logging into other machines on your network.
Add to that the fact your machine is then configured radically differently from any other machine, and you might not remember that when you switch machines, upgrade, etc.
So, in general, I'd agree with your friend - this is a bad idea, although not fatal. Far better, in my opinion to specify the path to /usr/local/bin/git when you need it, or symlink /usr/local/bin/git to /usr/bin/git if that's your specific need, or even setup a shell alias. Any of these options would let you get what you want (a lazy way to launch git) without potential risks.
By making this change for every process, you run the risk that some maintenance script written for a specific utility gets your substituted utility and fails.
In the same vane, no one should replace a standard utility in it original location with a replacement, again as a maintenance script could fail. Using, as you are, /usr/local/bin is a better idea, or similar location for utilities you want to add.
Generally speaking it is better to modify your own personal $HOME/.bash_profile, than it is to make a global change.
If you need the PATH changed for some GUI app, then you can create a $HOME/.MacOSX/environment.plist file. RCEnvironment from rubicode can be used to create and maintain .MacOSX/environment.plist files.
With respect to security, /usr/local/bin before /bin, /usr/bin, /sbin, /usr/sbin is only a risk if you all anyone to add commands and utilities to the /usr/local/bin directory, as those programs could then be a Trojan.
Thing is I don't have this problem just with git but with every bin which is both in /usr/bin and /usr/local/bin so I've to do symlink on all bins. I could remove the git on from /usr/bin coz i've got it twice but apparently it's a bad idea and could corrupt xcode for instance.
The best way, I think, is to add the path of a certain bin in your .profile like PATH=/usr/local/bin/git;$PATH; but so annoying to add path bin per bin.
And what about ~/.profile with PATH=/usr/local/bin;$PATH ?
nothing, except you syntax is wrong (should be a : and not a ; ). Also you need an 'export' command. If your syntax was put into place, the ONLY command that would be accessible would be those in /usr/local/bin, and all the standard commands would be unseen by the shell.
My suggestion (above) was to put this into $HOME/.bash_profile as it is the bash shell specific, however, as long as you do not have a .bash_profile, then bash will read .bash_login, and if you do not have a .bash_login, bash will read .profile
or symlink /usr/local/bin/git to /usr/bin/git
I think this is a bad idea (maybe not so much for git, but in general). The Mac user is not the only one that uses programs, commands, and utilities in the standard directories, and if someone replaces the original program with a substitute, some maintenance task or application that uses that program, command or utility may fail because the substitute does not behave as expected.
Putting stuff in /usr/local/bin (/sw/bin, /opt/local/bin, ...) and then changing your personal PATH is a better idea as that should not affect maintenance tasks.
If a GUI program uses some standard program and the user changed .MacOSX/environment.plist the app could still get burned.