Of locking files? Sure it does; if two people modify the same piece of code, then there will be a merge conflict, and whoever's doing the merge will have the opportunity to reconcile those two versions. It's like a lock, but you don't have to think about it / explicitly lock and unlock the object you're editing. Combine this with rebasing (git-speak for "switch to the branch into which I want to merge and then try applying all the changes from my branch") and you end up with a pretty coherent idea of what changed and in what order.

Having used both branch-oriented (like Git) and locking-oriented (not Perforce specifically, but my current dayjob involves very similar version control schemes), I vastly prefer the former. Less ceremony around doing things in parallel, and less risk of development deadlocks (e.g. Alice locked A.cpp for editing, Bob locked B.dds for editing, Alice now wants to edit B.dds, Bob now wants to edit A.cpp, now Alice will have to revert her lock on A.cpp, wait for Bob to do everything he needs to do, then relock A.cpp and redo her changes all over again (probably also having to debug new things because of new bits and pieces Bob added) - or Bob will have to do so for B.dds - and cue fistfight in the breakroom).

----

That all being said, binary files are indeed a weak spot for Git, so if you really do want to version control your textures and models and sounds and such, then sure, perhaps a different VCS tailored for that use-case would be more ideal. In my experience, though, that tends to be an anti-pattern; generally better to keep code and assets separate (I'm well aware that tools/engines like e.g. Unity don't play the slightest bit nicely with that separation), using separate version control systems tailored to the specific content.