Yet, as Hillel says in their post, 'Most people would agree that the software running on spacecraft counts as “real engineering”.'.
I think looseness stems from three interrelated factors (1) potential complexity of a piece of software (2) the role complexity plays in causing faults (3) the fault tolerant nature of many domains in which software runs.
(1) Potential complexity - literally the amount of logic branches - that can exist in a piece of software. If you were to compare the logic branches for a bridge, what would it be - 10? 100? if(load> X); if (temp > Y); etc...
(2) The reality is you can hold a bridge (or the relevant variables[0]) in your head. Holding it in your head is necessary to be certain you can think through failure cases, or even know what cases to conduct/write tests for.
When writing software, the branches can get so unbelievably high that it's basically impossible to hold the whole thing in your head. Even if you break apart and solidify each underlying abstraction in your system, a single user outcome may be composed of so many underlying abstractions that their interactions are impossible to predict.
(3) Going back to the '"...software running on spacecraft counts as “real engineering”.' I think this is a not-loose example of SWE . The stakes are high, and accordingly, I'm certain a lead engineer on such a piece of software would do as much as possible to fully understand the entirety of the system so that it can be precisely tested. Get the number of irrelevant variables as high as possible, and keep the complexity of code as small as possible.
OTOH, most software is low stakes. Even if you're dealing with money, transactions can be rolled back, payments refunded. There are rarely undoable mistakes, and even more rarely do those mistakes destroy the project (spacecraft) or kill a person.
---
So in summary - I guess my point is: SWE is its own thing, in creating a world where complexity is orders of magnitude higher than in physical things. "Engineering"-ness operates on a plane of rigor, the high end of which contains only certain kinds of software.
[0] I'd define an irrelevant variable as an abstraction that has zero possible implication for the logic branches of your project. For a bridge, this might be melting point of the steel (not a bridge guy, as you can tell); for a typical software project, this might be the OS.