Thoughts? I think the biggest counterargument is that it incentivizes churn like making a commit and then reverting it later.
If your engineers truly aren't getting shit done, you should be able to tell without looking at their code.
We don't get paid to write code. We get paid to _think_; it's just that if we don't write code afterwards, we get fired.
Therefore, a language that allows a programmer to turn thoughts into correct code faster is a win.
The size of the code as writter is only slightly interesting: almost everyone can type faster than they can think clearly. A more compact notation is preferred for reducing the delay between typing and testing, but not to the point of impairing readability.
Besides, you might as well start counting closed number of issues/tasks/tickets, story points or whatever, and skip the commit count altogether.
You could then go with features only tickets but those vary in size and complexity. Now, if we would put complexity as a measure (on which the team of developers should agree) and then measure the number of issues on that implementation we might get a better measure of that person's contribution.
That said, once that would be in place, even that can be gamed.
I think there is no silver bullet here, as much as we would like it to exist.