The state space of what you must check to ensure correctness in physical engineering is infinitesimal compared to ensuring correctness in software. Correctness in software is qualitatively more difficult by nature and an open problem at a theoretical level.

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 think being legally liable for any failures that pop up probably also has something to do with their more cautious culture...

Structural engineering, is engineering (though mechanical engineers would disagree), 'software engineering' not so much. It just happens to be a word that's a useful synonym for 'building things'.

I rarely call myself an 'engineer', preferring developer or programmer.

I agree with you but I would extend that observation to include the age of the industries. We have been making structures for thousands of years. Software is an infant compared to that.

I think that has more to do with than some unverifiable sentiment like "software people are simply inherently less serious than other engineers".

You do. Structures fail. Less so in parts of the world where serious regulations are in place.

Sometimes software is a public works project but sometimes it is a backyard shed. You just have to know the difference.

We don’t have time to tinker about for months on regulatory processes and making the our screws are “B6”. Software is a different industry.