Hmm. The point being that it might not be quick. The game state will mostly likely eventually differ noticably, but it might not be for a while. That would sort of make people think it worked perfectly, and perhaps encourage them to use the cheat. It may even have some of the intended effects due to lack of checking.
Say, if building units only checked money on hand at the time the command was issued (through the user interface), instead of the time it was executed (after it was send over the net), then anything received over the network might only have been checked by the sending computer, which could be running under cheat code. The state will differ since the cheating computer might think it has lots of money, and always allow stuff to build, while the other computers only know the real negative money state that results. The cheat may work if the other computers never check for negative money states, and just assumes the sending computer never lies. Such code could result in the difference in state never being detected, and so the cheat could function without it's results ever being visible. More likely though, there is some code that does check, but just might not run very often, such as repair code that takes money, and auto stops repairs when money runs out. Once those trigger a difference, that difference will grow into something more noticable. Think of the butterfly effect.
Essentially you want the checking code to run on all computers in a symmetric way, before the commands are executed, and then you won't have to worry about security and desyncs so much.
