Outside of a few niche areas, calling what's going on in software "engineering" seems laughable to me, and I never refer to myself with that term.
If it was super easy, we'd very likely change things once they were in use. Perhaps we didn't account for pedestrians using the bridge and they're walking across it all the time or tractor trailers are having trouble making a right off the bridge. Software is inherently "soft". It's malleable. When done well, it can create better fit to purpose solutions than almost any other discipline. I agree that most "software engineering" is more like plumbing, but I do feel like "real" engineering disciplines would likely follow a similar paradigm if they had the same luxury to rework things.
Look at the bay bridge, we built it using steel from china which, after it was already being used to construct the span was later found to be inferior.
So in SW dev -- you might choose a tool for a massive project only to find its the wrong/not best tool you could have selected based on the budget at the time the project started.
This can also be said of the team. Employee A was the right eemployee at the start of the project, but they later prove to not be the best resource, but youre already X% down the project timeline... what do? Esp at what cost.
One Job I had (at a top 5 consulting engineer) was to reverse engineer the code from an onsite survey computer and build a GUI to analyse the data allow one of our Senior Engineers to look at what happened.
So while your bridge scenario is correct, no one would do that midstream, software solutions often (but not always) can be flexible enough for change.
It's the exact same trajectory that happened with Lean Six Sigma. It starts out as a good idea in a specific area. People start making money on managerial self help selling based on the idea. Market saturates. Product is pushed into other areas to keep growth. Engineering management idea becomes cult-like. New method comes onto scene and starts to displace the old.
But to assume no real engineering goes on discounts the fact that aside from stories there are "detailed" requirements, modeling, and designing that still occurs. If your team is skipping this, that's a problem.