Perfect estimates: 
I’m probably expressing myself somewhat poorly since English isn’t my natural language, but we had the same point here. “You cannot train to make perfect estimates” — because that’s not possible.

Whether an estimate can be “technically correct” even though it doesn’t match actuals:
Here I just disagree. The whole point of the estimate is to be as close to the actual as possible. The further away it is, the less “correct” it is, and the less valuable it is. Again, whatever the root cause. Yes, you may adjust the plan and / or estimate during the project as new information or incidents occur, and you should — but that doesn’t change the fact about how good or bad the initial estimate (that were used to make the decision to go ahead) was.

JSF:
According to the executive summary of the root cause analysis, estimate errors was a major cause of the cost growth?

Not accountable for the spending of other people’s money: 
I am, we just go about it differently. We have limited faith in the accuracy of pre-project estimates. After concluding that we have a problem worth solving and the competency to do it, we’ll start attempting to solve the most important part of it, and deliver frequently. We still have cost control by assessing the value of delivery, and being able to stop or adjust if it’s not working out. I understand that this approach may be difficult in a 500M$ project. Our projects are also typically software only, so the investments are of course several orders of magnitude lower than, say, bulding a fighter jet.