Software development has different constraints. An edit -> compile -> test cycle is free, but formal verification of code is obscure and unwieldy. Consequently, our best practices are more iterative and empirical than front-loaded and model-driven. But we do have some. (Not denying that software engineering is much less mature than other forms).
A team that's doing good high-cohesion low-coupling components, fault tolerant design, unit testing, integration testing, version control, code review, capacity planning, telemetry, staging, canaries, blue/green or incremental rollout, feature flags, etc. is acting in accordance with the body of knowledge called "software engineering" even if they're doing it for a boring CRUD app. Someone with a big pile of spaghetti code on his laptop is probably not doing software engineering, even if he's cracked P=NP. (He might be doing computer science - have you seen how researchers code?)
Are there safety concerns that a lot of engineering doesn't have? Sure. But it goes both ways. In her field of engineering there are limited impactees and mistakes while potentially fatal have minimum monetary value. I can fuck up and cost my company millions in an instant. Or expose millions of user's personal information. Different risks, and I'd still probably take the a stolen identity over death, but at the end of the day it's a similar job.
No, but is most software work really engineering? Personally, and atthe risk of completely going off topic and starting a debate which has little purpose, I don't think so. I don't consider duct taping together various frameworks and third party libs to create yet-another-CRUD-app "engineering".