In other words, if your process involves predicting time needed to complete a project, you've already failed.
The difference was that in construction, the same subprojects have to be done over and over again, so subcontractors can easily be given and held to realistic deadlines, and your only bloat comes from the usual hiccups. On the other hand software engineers _by definition_ estimate things they've never built before. If they've already built it, they can just port it over and start working on something new.
Combine that with everyone's tendency to underestimate, inability to determine unknown unknowns, and the usual hiccups, and we're left with the usual refrain: accurate software estimation is basically impossible.
1 - You can fix the time or the scope of the project, but not both. I can say, "I will deliver project X in 4 months" but you have to be willing to let me toss out scope, and the earlier the better. This does work. Just like I can say, "I will promise to deliver all the scope in project X, I just can't promise how long it will take." Agile helps break this into smaller chunks, and allows you to get more visibility into what's realistic more quickly. I've seen too many waterfall projects slip by 3-6 months at a time only when the final deadline approaches.
2 - I've seen more projects slip because of "Unplanned work" and "Missed Dependencies" than due to "Misestimated work". It's either scope creep, or "I didn't realize we needed to test integration" or "Person X didn't give me what I needed." The only counter-examples I've seen are when engineers aren't consulted in the estimates.
Sounds like the Cone of Uncertainty: