A bad estimate gives you a handle on how easy or hard your engineers think that something is. Experience shows that this has little correlation with how easy or hard something really is.
That's a good example of a qualitative statement that would be a lot more credible with a lot of empirical evidence backing that up. "Experience shows" is not enough here. Raises more questions than that it solves anything here really.
Basically uncertainty is the key concept here. And cost, complexity, and time estimates are ways to get a grip on such uncertainty. Unlike software engineers, economists and sociologists are used to reasoning about and modeling uncertain situations. Going all hand wavy and winging it is typically not what they advertise.
And I'd argue that their bad estimate includes their knowledge of how difficult the task is. Unless you're completely broken, you're not going to under-estimate something wildly if you are unsure of what you need to do or have no idea how to do it.
Sure, I can give estimates that don’t underestimate and account for eventualities. It’s just that my error bars are large enough that in that case I have to estimate several months for tasks that I believe should take a week.
