The Damn DOM
Suppose you want to show a dialog and stop users from interacting with the rest of your site while the dialog is showing (i.e. you want the dialog to be modal). You achieve this by adding a semi-transparent div, sized to cover the whole window, behind the dialog but overlaying everything else. Presumably this prevents the user from touching the background content while the dialog is showing.
A more esoteric way the overlay can break is due to add-ons. A user may trim your site with Remove-It-Permanently, accidentally match your overlay with a too-broad rule, and not even realize the dialog was supposed to be modal. Worrying about all the ways add-ons can ruin your site is not practical, except maybe for the most popular ones (like adblock), but add-ons do make a nice counter-example to "there's no way for X to happen" for all X.
Another situation where trusting the DOM can bite you is reacting to input. For example, suppose you want to give dynamic is-it-valid hints as a user enters some text. You write a function to update the hint, and give it to the
onchange handler. Then you realize that handler only triggers when the focus leaves text box, not dynamically while the user is typing. So you change the handler to
onkeyup. Except users can avoid that event by holding a key and tabbing away before releasing it, so you add the
onchange handler back in. Which works great until someone uses their mouse to paste text via the right-click context menu. You need an
onpaste handler for that. Now you're finally- nope, you forgot one.
Imagine that the dynamic validation code is enabling/disabling a submit button based on whether the input is valid. Should the code that runs when the user taps the button redundantly run that validation, or should it implicitly assume the validation has ran based on the fact that the submit button is enabled? Doing a redundant check seems wasteful and needlessly complex, but if we missed an event handler then validation may not have run and we'll do wrong things.
Basically, omitting the validation means you're trusting the DOM, because you're relying on it to run the validation code at the right times. Explicitly running the validation before submitting makes the code a little more complex, but makes the background assumptions way, WAY simpler. For example, we're not catching "user talking into text box" events that don't exist yet. Can that bite us? An explicit check lets us fail gracefully in response to the DOM doing whatever the hell it wants.