Here's the issue:
I would be willing to bet large sums that conflicts would not be an issue in practice.The only reason they aren't here is because the locking system prevents it.
Let me explain: if people were allowed to have copies where they could change anything, we'd end up with a number of people who rarely updated. When someone finally did remember to update, there would be mass chaos. When you don't have to lock something, there is a tendency to just make the change and forget it. Eventually you update a large number of files. The result of this in practice is that your window of conflict goes up for all of the files you have changed, for the entire period between updates.
With a locking system, the tendency is to grab the file, make your change, and check it back in. The window of conflict for that piece is very very small.
In practice, the above has been borne out. During my recent porting stint, I have kept large numbers of files checked out for long periods of time; weeks for many of them. I have gotten a lot more requests that I unlock/finish with a file this past month or so than I ever have; the statistics I gave in the other post were from when I was using the system normally, not from porting. Porting efforts aren't normal as they touch large portions of the system at a time, and in tandem.
To sum up: non-locking systems with large numbers of developers will tend to widen the window of conflicts, as the effective contention period becomes much longer. Locking systems encourage short bursts of contention. I suppose an analogy would be a long running transaction vs. a short one.