If a program will only receive trustworthy data, and if it would not have to meet any behavioral requirements when given maliciously-crafted data, then it may be possible to generate slightly more efficient code than would be required if there were some behavioral requirements that it had to meet for all data.
Because some tasks only involve processing trustworthy data, while others involve processing data from untrustworthy sources, the C Standard allows implementations that are intended only for the former tasks to make optimizations that would be inappropriate in those intended for the latter, and for those intended to be suitable for the latter tasks to offer guarantees that would unnecessarily impede optimizations that could be useful when processing the former.
Unfortunately, the Standard provides no means by which implementations can indicate what kinds of behavioral guarantees they will offer beyond those mandated by the Standard. When C89 was written, the authors expected that "the marketplace" could do a better job than the authors of the Standard of determining what kinds of implementations should support what "popular extensions" by behaving at least somewhat predictably in cases where the Standard imposed no requirements, and such attitude has not changed even though it no longer fits today's compiler marketplace.
Given something like:
if (x != 0) launch_nuclear_missiles();
... and then, possibly in another function
some people would view a compiler that replaces the "if" with an unconditional call to
launch_nuclear_missiles() as superior to one that only calls
x is non-zero, but such behavior would only be appropriate when processing tasks that will never involve untrustworthy input.
If one knows that the compilers one is using will uphold the kinds of weak behavioral guarantees that general-purpose compilers used to offer as a matter of course, and which facilitate writing programs that could meet weak behavioral constraints even when given maliciously-crafted inputs, then division-by-zero might not pose security weaknesses. With aggressively-optimizing compilers that are not designed to be suitable for tasks involving untrustworthy input, however, it will be necessary to add enough safety-checking logic to negate any advantages such "optimizations" could have offered.