The locking people are talking about isn't locking for a commit
What happens in many proprietary systems, and in subversion if you choose, is that you need a lock to be "authorised" to edit a file, not to commit the change. The procedure looks like:
1 The lockable files start off read-only
2. You _tell the VCS_ that you want to work on file X
2.1 The VCS contacts a central server, asking for a lock on file X
2.2 If that's granted file X is set read-write
2.3 Optionally your program for working on file X is started automatically
3. You do some work, maybe over the course of hours or even days
4. You save and check in the new file X, optionally releasing the lock
The VCS can't strictly _enforce_ the locking rule, of course you could copy file X, or set it read-write manually, then start working on it, and only try to take the lock a day later. But, when you complain to your boss that someone changed file X after you'd started work on it, of course he won't have much sympathy.
The locking model has lots of problems, but some people have convincing arguments for why its appropriate to their problem. The only options for Git are (1) not appealing to those users (2) persuading them all that they're wrong or (3) offering some weird hybrid mode where there can be a central locking server for a subset of files. If you accept that (1) could be the right option, then the continued existence of Subversion is justified for those users already.