Because uninitialized memory isn't "it could be any possible value." Uninitialized memory is semantically an indeterminate value whose value is not guaranteed to be consistent between different reads of the value. Optimizations generally "choose" a value that is most convenient for eliminating code; for example, when comparing an indeterminate value to another value, it's easiest to "choose" one that makes the comparison just outright false. But these choices are not necessarily consistent between different uses of the value, since there's nothing to force the compiler to remember the value it chose.

(Note that it's not just the compiler that plays the game--a memory allocator might choose to use MADV_FREE for freed pages of memory, which means that at any point until its next write, the OS may replace the contents of the page with a zero page. So if a subsequent call to malloc reuses a MADV_FREE'd page, then reads of that data before anything it has been written to it may suddenly switch to a different value depending on the whims of the kernel.)

As I understand it, the compiler "knows" the range of valid values for a variable (for instance, if an int was promoted from an unsigned char, it knows it doesn't need to bother with testing for negative values). If the value came from uninitialised malloc'ed memory, the compiler knows that there are no valid values less than zero, no valid values directly equal to zero, and no valid values greater than zero - thus all three tests fail, and the overall negated test always succeeds!

Because it invokes UB.