Give more explanation in the "Obvious Fix" rule

CONTRIBUTING.md

@@ -129,15 +129,24 @@ include things like fixes for obvious typos (e.g., a misspelling in a
 comment or in a user-visible string), source code formatting changes
 (e.g., removing trailing whitespace from lines in preparation for a
 substantive change to follow, as per the ["keep unrelated changes
-separate"](#keep-unrelated-changes-separate) rule), etc.  You may use
-your judgement about what constitutes a trivial change.  After all,
-everything is under version control, so if someone makes a mistake, or
-there is disagreement about the effects of the change, then we can
-roll back and discuss.
+separate"](#keep-unrelated-changes-separate) rule), etc.
+
+The purpose of this exception is to avoid paying the costs of the
+review process in situations where it's unlikely to bring benefits.
+Going through review is good for quality, but it reduces velocity and
+increases the state-maintenance burden for contributors -- an unlanded
+change takes up space in people's minds as well as on MR lists.  For
+most changes, that cost is worth paying, but not for all.
+
+You may use your judgement about what constitutes a trivial change.
+Everything is under version control, so if someone makes a mistake, or
+there is disagreement about the effects of the change, then the group
+can roll back and discuss.
 
 Note that individual projects may use stricter review guidelines, if
-the development team wants to.  Specifically, some projects don't make
-the "obvious fix" exception: everything goes through pre-merge review.
+the development team chooses to.  Specifically, some projects don't
+make the "obvious fix" exception, and prefer instead that everything
+go through pre-merge review.
 
 ## No surprise rebasing