Im going to assume those are big commits.. I personally would do a commit for every little class or method I write. I did 18 last week for example.
Also I'm curious what he means by 'burnout' I'd take that to mean mentally exhausted from too much stress. Sounds like he was more vaguely dissatisfied or unmotivated.
In many cases you'll need to get your code reviewed by an external team, and oftentimes their SLA for one round of code review is 24 hours. That a.) incentivizes big commits and b.) sets a floor on the latency of your commit process.
My long-term average at Google was 5 commits/week, max was IIRC 24/week, and min was 3 months to get one commit written, reviewed, and approved. By contrast, when I'm coding on my own for my startup, my long-term average is 20 commits/week, max was about 14/day, and min is about 1/day.
Obvious caveat: there are 20,000+ engineers and hundreds of teams at Google. Things aren't exactly the same everywhere.
In any case, I think 5 per week is extremely reasonable; I actually do less these days. I used to commit a dozen or more times per week, but these days I tend to work on the larger and harder components that people require. That means more thought and more design. It's not doing less work, it's just doing harder work.
This person may also have had review reponsibilities. Doing a truly thorough code review takes time to complete, and that time is time that you're not coding. It's important though; I may not be coding while I'm reviewing, but I'm sharing knowledge with a dozen other developers who hopefully learn from it (as I learn from others reviewing my own code). In aggregate, I hope that my lack of frequent commits actually helps the company rather than hurts it since hopefully I'm enabling many others to do better work.
At least, that's the way it worked when I was there. I sure as hell didn't get 5 commits in a week.