I think software systems whose failure directly jeopardizes human lives should be engineered, and should be defined and enforced legally. Systems that don't directly risk human life should not be so constrained.
Defining that standard and enforcing it is a huge task which could easily go very wrong.
Businesses would of course be free to apply the "engineered" standard to any systems they choose to. Outside of mission-critical systems operating at gigantic scale (FAAMANG-level) I doubt it would often be profitable to do that.
The hypothetical standard would also be less relevant when building proofs-of-concept, so long as the POC is not usefully deployable (if it is there's risk of someone deploying it despite it being unsafe).
In the end, most software does not put human lives directly at risk. Acting like it does would waste resources and doom many small businesses whose profit margins couldn't absorb the costs of genuine engineering (it could kill several companies I have worked for).
Even software systems that do risk human lives don't do so in all subsystems - as far as I know, painting a mural in your skyscraper's lobby requires no engineers to be involved. Similar distinctions may be reasonable in sufficiently-isolated components of software packages that do some life-protection tasks. Maybe allow a formal verification to show that subsystem X cannot impact the critical subsystems and therefore does not need the same level of rigor?