In most applications, the way that guess is made (ie: which candidate cell+digit is selected to try) is neither here nor there, 9 x 9 Sudoku solvers can solve even low-clue, minimal puzzles, so fast that it is unlikely to matter.
It is only when we move outside the safe world of 9x9 puzzles, into, say 16x16 puzzles, or multiple 9x9 overlapped grids like Samurai, that we discover the potentially catastrophic consequences of the "bad guess".
"Guess Theory" asks the fundamental question:
Q: What candidate should we try next?
but sadly, everything we know currently suggests only one answer:
A: I have no idea! Your guess is as good as mine!
The most common NCS (next candidate selection) strategy is what I call the "taxi-rank" method. TR selects the cell with the minimum NPV (number of possible values), and where there is multiple choice, takes the first one in the list (however this list is built), and then takes first (lowest) digit candidate for that cell.
Mladen dobrichev found that a tweak to this method gave better results (overall) for 9x9 puzzles. In his fsss2 solver, given a choice between cells with the same (minimum) NPV, he selects the digit first, ie the lowest digit that appears in the candidate list, and then the first cell in the list that has this digit as a candidate. So effectively he has inverted the TR method to pick "first digit" then "first cell". I call this method MR (Mladen's Rule).
I ran extensive tests using only low-clue 16x16 puzzles, and compared these two methods, plus a 3rd method, XR which is just "select randomly". These tests showed that the only appreciable difference between them (in terms of the # of guesses required to solve), was that different puzzles resulted in bad guesses for each method. Yes, the XR method was inclined to encounter more "bad guess" cases, but really there was little difference. Especially when just a single instance of "bad guess" syndrome was like running into a brick wall - solve times went from the milliseconds scale to HOURS in some cases.
Unless one is willing to spend some time looking at the full search-tree below (ie some form of look-ahead), there is little that can be done to avoid these cases. The only effective "pathological case prevention" method is to apply "guess limits" - so the solver now has an extra return code to indicate that this limit was reached. One can then try an alternative NCS method, and most of the time this will work.