You don't see the same problems in say, structural engineering as you do in software engineering. I suggest this is due to needing to go through the formal training required of a structural engineer, and membership bodies like chartered institutions, with standards and codes of ethics. We might want to reflect on that
No amount of bureaucracy and process theater gets around this fact. There is a vast and very expensive gap in software between "don't do stupid things" and "this is actually correct". The tooling to close this gap is severely deficient and not for lack of trying. In physical engineering we've had automated design checking for decades because it is a relatively trivial problem in those domains.
It would be great if compilers could generate proofs but after decades of research they can't even generate SIMD code in most contexts.
I rarely call myself an 'engineer', preferring developer or programmer.
In Europe, a lot of supermarkets were hit by a remote exploit which allowed attackers to switch off cooling of food. A blood bank in France was attacked the same way.
So how would building software for important or even safety-relvant systems not be considered "engineering"?
Especially, as faulty software might not only cause a product or device to fail in a dangerous manner, faulty software in this day and age often makes it possibly to remotely attack the faulty product.
I think that has more to do with than some unverifiable sentiment like "software people are simply inherently less serious than other engineers".