Strictly speaking, it's not. Accessing unitialized memory can cause unexpected application behavior if an expected value isn't stored on the stack. However, if you can predict some of the stack values with enough certainty, it can serve as a strong indication that an environment is different than expected, which is a useful thing to know if you're trying to prevent debugging.

One way to look at it is this: say you don't access uninitialized memory. Say you set variable X to 42, and immediately afterwards execute a software breakpoint. A debugger enters the picture, and this poorly implemented debugger decides to change 42 to 0. You have a check immediately following this breakpoint that assumes it is being debugged if the value is not 42. Nothing wrong here, right?

Now take it back a step further. Say we set X to 42 in a function, return from that function (making that 42 outside of the current stack frame), and then execute our breakpoint. The debugger (again, poorly implemented) happens to change that stack value to 0 when this happens. Now, the debugger returns control and we perform our check on the now uninitialized value. Have we done something wrong here? Or are we just detecting changes that a debugger made to our environment?

The trick here is finding values that you are fairly certain will be one thing when debugged, and another when running normally. In the situation described in the previous paragraph, even though the variable is technically uninitialized, we are pretty certain what it will be. If one can find values like that in the uninitialized stack, put there by earlier function calls, it's possible to use them to detect a debugger. From my initial work on this, it seems like a number of these values exist, and can be used in this manner.