I'll grant no one will read this but you (maybe?), since it's so far off the front page and everyone else's radar. Overall, your thoughts are excellent, but I have a bit of a bone to pick here:
(I recall one coworker at a job, when we looked, had done 12 CVS checkins during a given period where the average was close to 100 and the next lowest was in the 30s, or something like that. Illustrative!)
Not a good example. Number of commits is an n-th level approximation to measuring productivity. As an example from my own life recently, I just finished doing a massive refactor on a rather integral part of my current employer's website.
Due to the bad shape this module was in, any change I made to it would result in a broken program until I had done a considerable amount more refactoring both within the module, and all the other places it was tightly coupled within the code. The philosophy of "if it works, don't fuck with it" didn't apply here, because it didn't work when it was thrown my way, and it was almost indecipherable as well. So I set to work refactoring, more to decipher the code than to fix the problem; it was impossible to keep enough of a logical model of it in my head to reason through the misbehavor. Every time I changed something, 3 other things would break, making building the mental model I needed even harder.
For a number of weeks, I had something non-functioning, and something that would be completely worthless if committed into repository (I was backing it up elsewhere at the time). The best these commits would've been is the SCM version of status reports of a system without cohesion, which would have been a complete waste of everyone's time.
To be clear, I am absolutely against monolithic refactorings about 99% of the time, and I did a tremendous amount of soul-searching through all of this. I worried that I was making this far more difficult than I needed to make it, that there were smaller changes than I was making that would allow everything to work out. But every time I'd try to find a easier way out, I'd hit a point where I found such tight coupling that changing one thing would necessitate 20 changes elsewhere, and things would cascade from there.
When I got to a point where it started functioning again, I committed all the changes in at that point. One commit, but a lot of lines of code, and even more deep thinking went into this work. At this point, I am now committing more frequently, as the remaining issues are worked out of the rewrite.
I guess the moral of the story here is: don't just focus on the number of commits, focus on what went into them. If these 12 commits were on par effort-wise with the 30 commits on average of everyone else, something is wrong; otherwise, the guy hitting 12 commits might just have deeper, more difficult work to do.