I think the perception that programmers are less attentive to failure modes than other engineers is an artifact of two things:
1. Computer programs are far more complex (and complex in a hard to analyze way) than mechanical systems
2. Programming is (still) a relatively immature field, and, and a result, it doesn't have the institutional knowledge and best practices that make certain failure modes highly unlikely
I think (2) is an underappreciated point. If you look at the history of e.g. boilers and steam engines, the early years are absolutely rife with examples of boilers and steam engines exploding in spectacular ways, often killing people in the process. It took years for standards of design and engineering to develop which made those failures exceedingly unlikely. Another example comes from aeronautical engineering. The Comet jetliner, for example, suffered from cracks that developed due to metal fatigue that was exacerbated by the design of the windows. These cracks led to crashes that killed hundreds, and, in response, standards were created and modified to ensure that window frames were properly designed and reinforced to prevent cracks from propagating. Furthermore, Dan Luu has done some work [1] in analyzing how cars fare in accident types that haven't been incorporated into safety standards, and he finds that their performance is often quite bad.
Most "traditional" engineering is like that. It's not that the engineers are personally paying more attention to failure modes. It's that they're following standards, and as long as the standards are followed, the failures that necessitated the creation of those standards are prevented. Programming, unfortunately, is still new enough that many of the standards we need haven't yet been developed, and most practicioners are new enough to the field that what standards do exist haven't really propagated across the field.
[1]: https://danluu.com/car-safety/