There's also a tendency to leave out important information. I recently worked on a project where 1) more than half of the features were not in the requirements because the product manager assumed we could re-use existing functionality from a completely separate application (we couldn't); 2) half of the requirements from the new work were left out of requirements because they didn't bother to specify them; 3) a critical requirement regarding how data was to be aggregated in search results (which is the primary feature) was not included because the architect didn't bother to tell anybody about it except for a passing "hey, what if we did this instead" before going on vacation. This caused 2 weeks of re-work after we were done, that would have taken 2 days if we did it from the start.
Our engineering team reviews all requirements as a team before giving estimates and this STILL happened, because we couldn't know what was missing. Good estimates begin with good requirements, and usually the people responsible for those do not end up being accountable, it ALWAYS falls on engineering.
Also ...
Do we really think that every project is such a unique snowflake that we can't build models?
Well, yes. That's inherent to what we do. Every project IS a special snowflake. If it wasn't we'd just download the software and install it. Oddly enough, installing and configuring software that is pre-made is very predictable and such projects rarely overrun. The sort of projects we're talking about are where pre-existing software won't do and thus, by definition, what you need is something special.
Meanwhile even very ambitious tunnelling projects like the Gotthard Base Tunnel, if you watch documentaries about them, they only hit a very small number of really unexpected issues even over long periods of time. Tunnelling is an incredibly predictable business. You buy some TBMs, set them going and worst case, you hit unexpected rock types or have an unexpected malfunction. The technology is advanced but rock is the same as rock has always been. Once the project planning is over requirements don't change. The course you're on doesn't change. Workers are largely trainable and replaceable - you never find you're unexpectedly relying on some random worker somewhere deep in the org chart who is 50x more skilled than their coworkers and who just got poached by a company that pays 3x as much as you can. The users/customers have no input: they get what you deliver and a tunnel is such a simple thing talking about whether they like it or not is a nonsensical question - it's a tunnel.
That's about as accurate as saying that software projects are only unique in trivial ways because there's probably already a free library or plugin that can do whatever else you need. It's easy to assume your occupation is much harder than everyone else's but we rarely have deep knowledge of the challenges other people face day to day outside of our own line of work.
As a simplified example, the design of a road, its pavement layers and its foundation is determined by factors like traffic loading characteristics, service requirements (peak capacity), speed limits and visibility, ground conditions, climate and more (see Caltrans' Highway Design Manual at http://www.dot.ca.gov/design/manuals/hdm.html), many of which rely on professionals in entirely other fields.
To make what I hope is an apt analogy back to software, you are basically saying, "Oh, their job is easy. All they have to do is follow established design patterns!" But, of course, we also have design patterns... Why don't we say the same thing about ourselves? Because we know that that's complete bullshit; there's a lot of thought and wisdom that goes into actually building stuff around those patterns.
Fogbugz created a feature called Evidence-based Scheduling (http://help.fogcreek.com/7676/evidence-based-scheduling-ebs). It's probably the only real quantitative approach that I have seen while working on web development projects. I'm probably wrong to assume that more "technical" fields like aerospace do much, much more than this, but it was really interesting to use this with what was mostly CRUD-work.
EDIT: added link.
More like: Previous work shoes that this project should take between one week and eighteen months at a 95% confidence interval.
...there aren't many projects one can do 300 times to narrow that window. And asking for a date instead of a confidence interval is asking for an ambiguous estimate in the first place.
We are not there yet, but are moving in that direction. We weren't previously even collecting the metrics required to create models in the first place, so we didn't have any data.
Of course, this is not all on engineers either. I'm sure everyone has seen the project manager who takes estimates as commitments. Cultures that allow that to happen will see repressing of generally good estimates. (If you use modeling, you just boost your confidence interval appropriately. 6 months at 85% or 9 months at 95%? Pick which number you give based on your experience with the PM!)