I think one can reasonably argue that sufficiently large fines that don’t have a „but we followed iso-xyz“ loophole could produce better outcomes. The difficult part is making the companies care about existential tail risks.
I wasn't able to find much information about U.S. P.E. certification for SWE's, although there is at least one state which offers it. I wasn't able to find any indication anywhere that a compliance process requires a P.E. to sign off on software. That doesn't mean it doesn't exist though!
One major problem is that now that software is "everywhere" it's escaping the boundaries of safety critical standards. Nobody will be killed directly by a bank getting hacked, but it could result in mortal harm to an individual who has their identity stolen. There are all kinds of systems that aren't labeled safety critical in the kinetic sense which are nonetheless very load-bearing. Software which runs on phones, for example. Surely people have died due to buggy phone software. Nobody is being held meaningfully accountable, so it will continue to happen.
To be clear, I'm not saying we should heap a whole lot more pressure onto security teams. Instead we need to find better ways to make security every engineer's professional ethical responsibility--either directly because they're signing off on the system or indirectly because their respected senior colleague is. I just don't see fines getting us there.
For better or for worse, that's how we've set up our system. The entire point of incorporation is to separate the people working at a company from the company, legally speaking. The most they can really do is fire you.
With respect to valuation-cratering, that's supposed to be considered fair in our system. If a bunch of shareholders elect a board that lets a C-suite operate a company with lax security culture, they're ultimately responsible for the losses they incur. It's only fair; they're the ones getting the profits, too.
I put emphasis on "supposed" because we don't really do this anymore. Instead of expecting shareholders to take the bath, we shift the loss onto the customers, who have to put up with the consequences of identity theft out of their own pockets.
We don't have bridges falling down left and right, airplane crashes aren't common, trains don't leave the rails every day. Software is all grown up now, and we need to grow up as a discipline whether we're ready or not. It'll get a lot worse before this happens, but I'm convinced it will happen eventually.
I'd say some of that depends on the domain that the software is developed for. I've spent most of my 12 years developing software in healthcare IT. Typically, you don't see too many critical (meaning life-threatening) bugs in EMR/EHR software, which is one of those domains where you'd think it'd be easy to run into that sort of thing. Most of the problems in the domain have to do more with data access being granted or obtained by someone who shouldn't have it. You won't die or get seriously injured as a result of the software, but some guy in a dank basement outside Moscow might know you need your knee replaced.
A lot of that comes from the fact that software for systems that could have a bridge collapse-level of impact are already certified as a part of a larger regulatory scheme for the domain in which the software operates. Healthcare and avionics software instantly come to mind. A lot of people in the KC area make their living writing software for those domains, and while they aren't required to have an engineering license to do so, their wares have to be vetted enough that they have to work at the same level.
You'd need to convince lawmakers to set up a regulating body that tracks business and consumer software for security in the same way we do EHRs for patient safety risks.