Many folds in InstCombine are limited to one-use instructions. For that reason, if the use-count of an instruction drops to one, it makes sense to revisit that one user. This is one of the most common reasons why InstCombine fails to finish in a single iteration.
Doing this revisit actually slightly improves compile-time (http://llvm-compile-time-tracker.com/compare.php?from=97f0e7b06e6b76fd85fb81b8c12eba2255ff1742&to=fc740dee13f42a948b378d731e666d0a80d16061&stat=instructions:u), because we save an extra InstCombine iteration in enough cases to make a visible difference.
This is conceptually NFC, but not NFC in practice, because differences in worklist order can result in slightly different folding behavior.
This is a bit unfortunate, but I believe it's ultimately not a problem. The two lshrs here are the same instruction and will be CSEd, at which point this reduces to the same IR. Similar for the test below.
I double checked the worklist order, and the new one is "more correct" (i.e. follows instruction order more closely), but happens to produce worse results in this instance.