Regarding the hotel clerk fix:

The original algorithm takes the last three bits of the random number to determine the result. The fix, however, takes the random number modulo 6. This is going to yield different results in most cases.

One particular issue, if we assume the RNG is equally likely to generate numbers anywhere in the 0 to 255 range, I note that values of 4 and 5 are slightly less likely than the others; therefore, the stats corresponding to those two values are less likely to be increased. This is not the case with the original algorithm (again, assuming that all values from 0 to 255 are equally likely, which might not necessarily be the case).

One other way to prevent there from being no stat increase, while preserving the frequency at which the stat increases, and which requires fewer code modifications, is to change the target of the jmp instruction; instead of having it jump past the stat boost logic, have it jump back to where the RNG is called. In other words, instead of not getting a boost if a 6 or 7 is rolled, reroll until you do get a boost.

Of course, I have no evidence that the RNG is fair, and it might very well not be. To determine for sure, one would have to disassemble and study the game's RNG.