The OP's claim is definitely too strong. Even if you're not in a hot path, code that immediately entirely fills a chunk of memory with data doesn't benefit from changing the allocation from malloc() to calloc().
I'd very much recommend that advice; use it all the time, remove it only when it proves to be a problem, and then, as always when optimizing, bear in mind that you've chosen to juggle lit sticks of dynamite and prepare accordingly.
[1]: I hypothesize that this is because what "really" comes back from a malloc is basically too impossibly complicated to model by a human. Even calling it "random" isn't correct; it's not random, but what it is is very hard to characterize.
I think "uninitialized" is the word you are looking for :)
Uninitialized isn't "a mess that you really ought to clean up before using", it's radioactive waste.
If you want to tell me that you really do think of "uninitialized" that way every time you use it, I have no grounds to disagree with you personally... but based on the code in the wild, it does not seem that most C programmers do have a correct understanding of the issue.
(People who develop the proper level of concern about handling radioactive waste tend to find ways to stop programming in languages that don't default to handing back nuclear waste on every memory allocation. I suspect some form of evaporative cooling may be a problem here.)
But how does replacing that radioactive waste (neat analogy) with zeros improve correctness here?
It doesn't improve correctness it limits liability of incorrect code.
Coming to C with a mental model of memory from another language is a recipe for security problems.
The next person may have equally likely (or maybe more likely?) simply forgotten to initialize some particular field and now you've got a problem if the field is supposed to read 0 most of the time and maybe sometimes 1.