No, like all management fads, it just needed time to percolate. Now that software is so big, people who grew up in the agile domain have been promoted through the stacks to general engineering managers and have taken Agile with them. This means that folks in the hardware domain are now having to explain that you can't just keep iterating on ASIC's because it is really freakin expensive to make iterations.
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.
Yes, but that isn't my point. The OP was griping about the difficulty business people have in seeing where the effort happens in software to produce something customer facing, and the dysfunction that happens from that inability to see it. He then wonders in a coda how big infrastructure projects ever succeeded with that kind of disconnect. I'm saying that a big factor at play is that agile subjugated the tech to the business in a way that large nuts and bolts engineering projects simply aren't allowed to do: requirements - down a fine level of detail - have to be provided up front. Once engineers in those domains have their requirements, they are really free to use their expertise as engineers. I don't mean to imply I'm a proponent of "waterfall", but it bugs me that agile evangelists think they've found The One True Way to do software, and don't acknowledge what I think are serious impediments to calling the act of writing software "engineering".
I see your gripe, and customers being promised demo's after every sprint is a bit over the top in many cases. Especially large projects.
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.
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.