How would I know when these drivers/servers need to grab the memory? or in what kind of situation?
[/quote]
You don't have to worry about that. An example might be if you're using OpenGL or DirectX - at some point the textures/meshes/shaders in your process needs to be copied to somewhere the driver can access. To do this, the driver needs to get a pointer to your data. If for whatever reason the language mandated that blocks of memory, when first referenced, are zero initialised, then it wouldn't be possible to write this logic in that language.

Drivers shouldn't be randomly accessing your processes memory while you're running normally though (although something read-only like a virus scanner might).

I think it is a moot point here in userland though. I also cannot see a language specification that would require memory allocated outside the control of the runtime to be initialised to any particular value.

But predictability and consistency is still useful for release builds - and in particular, it's desirable for release builds to have the same behaviour as debug builds. Unless you like having bugs that only show up in release builds.

I'm afraid that if you are seriously suggesting that a debug build should not generate code that could potentially behave in a different way to code produced by a release build, I think you misunderstand some fundamental concepts.

Bugs that only show up in release build are incredibly common.

As relates to this debate, a debug build of a program could cheerfully inject the overhead of zeroing out the stack when local variables are pushed in a stack frame. But no sane compiler would inject this overhead into a release build unless asked to. The overhead would probably not be significant to the end-user of a compiler but the guys who write compiler code-generators cannot think in these terms as they cannot predict use-cases.