I would first like to acknowledge that this answer is somewhat speculative; this is the first time I've seen this feature in a a chess engine, and I'd be interested to know what other chess programmers think of my answer.
Contrary to what is commonly believed, (good) chess engines don't just "search all possible moves" up to a certain depth then pick the best one. If we were limited to this, modern engines would only be ~1600. An incredibly, stupidly important idea in chess programming is that of "reductions." There are many different types, but the basic idea is that computers don't search some lines it doesn't consider promising.
Of course, this is a very double edged sword. On the one hand, you get much deeper and more effective searches, but on the other you are destined to miss something. To give you a taste, consider the following position:
[FEN "3n3k/rp4pp/1p5r/pPp1pp2/PpPp1p2/3PpPp1/RN2P1P1/QBNR1BK1 b - - 0 1"]
I'm confident a reasonable player can find the simple mate for black (get both rooks on the h file, and mate on h1, after Ne6 to ensure that White cannot break through), but Stockfish 10 can't find it at "depth 50". This happens because the mate involves like 7 consecutive quiet moves, which Stockfish doesn't see as significant enough to warrant intensive search. (Another example on Lichess.) When engines miss tactics, most of the time something like this is to blame.
One of the most common forms of this technique are "late move reductions," wherein the computer selectively reduces moves found later in the move ordering. (this sorta presupposes you have semi-decent move ordering, but you said you already knew a little of that, so we're skipping it).
Next, iterative deepening. Basically, the idea is that if you ask Stockfish to search at depth 25, it will start by searching depth 1, then depth 2, then depth 3,... then depth 25. This seems like a stupid idea at first, but it has various benefits most of which I won't go into. What's relevant here is that the depth 24 search informs decisions about reductions the depth 25 search makes. So if depth 24 says a move isn't too promising, depth 25 is less likely to search it deeply. (this is a massive simplification).
Ok so what's happening in the commit?
The effect is that in positions with many 3-fold draw lines, different lines are followed at each iteration. This keeps the search much more dynamic, as opposed to being locked to one particular 3-fold.
Here's how I'm reading this: Before the commit, the computer will be searching the same draws at every iteration. If there are lots of 3-fold lines, it's possible the computer won't search all of them (or at least, all of them deeply). This can lead to "blind spots," where the computer doesn't notice some sideline in a move with a draw score.
Before the commit, each successive iteration would have (roughly) the same blind spots (albeit with more resources to notice the sideline). After the commit, the blind spots are scrambled at each iteration, making it less likely to miss the sideline.
As a toy hypothetical example (which shouldn't be taken too literally): say we have two "draw" moves A and B, both of which are way out at the horizon of the search. Because they are so far away, the computer's evaluation of them is very bad (for several reasons, but for the time being we can just think that only a few of A and B's children are searched due to reductions) so it's possible A and B aren't actually draws.
Now for whatever reason (perhaps reductions), let's say the computer has allocated 5 resources to search the "best" draw move and 3 resources for the "second best" draw move at iteration 24, while allocating 6 and 4 respectively at iteration 25.
Let's also say A is a genuine draw, but B has a sideline which isn't, and will be noticed if it is searched with 5 resources.
Before the commit, if A is searched first at iteration 24, it will likely also be searched first at iteration 25 (meaning the sideline slips through), but after the commit, A and B are equally likely to be searched at each iteration, meaning the sideline is more likely to be found at some iteration, whereupon the computer will take note and correct.
I don't know if that made any sense whatsoever, but I hope it helps.
Again, I'm very open to being corrected here. This is just my reading of the commit.
