"Nobody wants to go and say that the uncertainty cost is 100% of the project cost"
As a software engineer, I completely agree. This is why we do Agile (and friends), so estimates are just weeks out. But what do you do when you need to plan a decade-long project? Software industries avoid those, so I guess we're fortunate.
Plenty of companies do fake agile where they want an estimate of the complete project before its even fully scoped. Often, that estimate is made up by someone who has no idea about software engineering, like sales or the CEO. Then the sprints are made to "conform" to the estimate. Eventually someone figures out the original estimate was completely wrong and someone else wonders why the project is "late." Often, something have baked is delivered, "meeting the deadline" is celebrated, then another X weeks is spent "fixing bugs."
"Fake agile" is so pervasive at this point. It's just waterfall, but without having to bother planning out the other end of the waterfall and hiding it all behind scrum.
The difference between hardware and software is that you design hardware first, address most of the uncertainty, and only then build the thing. You can't reliably plan the design phase for hardware. Too many unknowns that have yet to be found out about. Just like with software designs.
With software, the process of designing and building are the same. Upfront you know nothing, then you start iterating and at some point you have the finished thing after you've progressively learned all the requirements. There is no separate build phase. People used to pretend there was and that never really worked. The end result of a software project is an executable specification. The process of specifying is all that ever happens. Writing a specification for the specification is not really a thing. At best people attempt partial, very incomplete and hand wavy specifications. But it's not the same thing and it typically lacks the rigor of a hardware design.
Agile hardware design is increasingly a thing as well. E.g. SpaceX is iterating on their rocket designs. This is not some grand design they came up with years ago but a specification that they keep on refining by attempting to build it and by learning from the failures. The number of iterations is not a fixed number. It's as many as they need to. They build parts, tools, and machinery along the way as they discover what they need. Very different from how rocket design used to work. And apparently a lot cheaper too.
Imagine you're starting from scratch. You want create a company that will make a fancy new database. You need to know things like how many people you'll need to hire, how much those people will cost, and some idea of how long a viable project will take.
There's no scrum team yet, as you haven't hired them. You still need to generate some sort of answer.
As a software engineer, I completely agree. This is why we do Agile (and friends), so estimates are just weeks out. But what do you do when you need to plan a decade-long project? Software industries avoid those, so I guess we're fortunate.