There are two legitimate concerns in a debug context. The first is predictability / repeatability; zeroing is substantially more helpful than randomization in this context.
The second is revealing incorrect assumptions / fuzzing / stress testing; zeroing is substantially less helpful than randomization in this context.
Ideally, both options would be available. When someone says "give me a debug build", I think it's probably correct that they are caring more about the former, but really it should be clear and controllable.
No, that addresses reproducibility, which is worthwhile but is not the same as predictability.
Predictability in this context means simplifying the problem. If uninitialized memory is nulled, then I know what I'm looking for/at more quickly. Likewise if it's set to any other particular, known value. I know it will (or won't) be failing null checks, and I know that it will (or won't) be segfaulting if dereferenced. This helps with characterizing and fixing bugs, (related to but distinct from detecting bugs in the first place). Relying on this to make the program work is bad, but that's not the same thing.
The second is revealing incorrect assumptions / fuzzing / stress testing; zeroing is substantially less helpful than randomization in this context.
Ideally, both options would be available. When someone says "give me a debug build", I think it's probably correct that they are caring more about the former, but really it should be clear and controllable.