Of course if you just take point samples, it fails as you say.

But I don't think people really understand what LOC stats look like in practice for engineering teams. The pattern I've consistently seen --across several companies and many teams-- is that most low-performers simply don't commit very much code every month/quarter/year/whatever. I'm not talking about the senior engineers whose job is architectural design and advising and code review, and so on, who contribute a ton to the project without a line of code. I'm talking here only about junior- or mid-level software engineers whose job is supposed to be hands-on-keyboard code. You will always find a number of them who simply push very little code of any significance, compared to their peers. This will be visible in their commits.

So while it's true that there's no function productivity=f(LOC), there is still information to be gleaned from reviewing the commits (in detail) of everyone on the team, and often one will see a correlation where the people who are not delivering much value to their team (they fix only few bugs, or they take a very long time to implement things, etc) they more-often-than-not have very low commit stats overall.

Sure, this is useful for the outliers who just straight don't work as much, but much less useful for telling the difference between a busy person and a productive person.

I have seen bad devs who make daily commits with tens or hundreds of LoC, but whose tools never actually convert to production use because they are mired in development hell, until someone pulls the project away from them and hands it to someone else.

Devs who are so bad that they legitimately spend weeks trying to make a tool that I then built in 2 days.

I think LoC irks me so much, because if I finish someone's "2-month" project in a week, LoC optimization effectively penalizes me for it.

If you insisted on good git hygiene, then I'd have a lot more time for commit count as a productivity metric, and even LoC to a lesser extent.