> I’ve actually seen two contrary kinds of advice

and the best approach is most of the times something in between.  Doing minor cleanups while touching the code is fine, but if most of the changes are cleanups then it gets distracting.  In that case it's better to do the cleanups in a separate commit (either before or after).

Regarding rewrapping paragraphs in the docs the situation is a bit different.  There are 3 options:
1) change and rewrap in the same commit;
2) change but avoid rewrapping so that the changes are easier to detect;
3) like 2, but then add the rewrapping in a separate commit;

3) is overkill IMHO, and I don't think I've seen it used very often.
2) makes the diff more readable, but leaves the code unwrapped making it less readable for everyone else (and I would argue that reading code happens more often than reading diffs).
1) makes the diff less readable, but leaves wrapped code and it's IMHO the best compromise, and thus what I usually do.


However, I think that the actual problem pointed out in the linked issue is about mass changes, rather than cleanups while touching code for other reasons.  Even for that it depends on the case: how many files/lines are affected, what benefits are brought by the change, how complex are the changes, how likely is to introduce new bugs while doing them and so on.

A couple of generic guidelines could be added to the devguide, but there's no hard rule for this.