Good point. I was careful to say "big" as well as "multi-purpose", because I think most of us are more comfortable with "big" commits than "multi-purpose" commits, and a commit that is both should send off red flags.
Specifically, it's hard to code review multi-purpose commits because you have to think more extensively about the side effects, risks, regressions, etc. for unrelated changes that are lumped together. If it's a small commit, that tends to not be an issue, but if you're touching several unrelated areas in a big commit, it gets really tough. And as a general best practice, you want your code to be easy to review.
Who thinks this?
> A couple of those points could be boiled down to "use a strict linter with most of the rules turned on".
Now I'm not so sure.
> Do you mean linters that enforce maximum line widths? That seems increasingly rare these days.
Yes, that is what I mean, and I see it more and more because some think passing a linter test will make your code good.