I think a big part of the problem is that nobody ever teaches developers how to estimate and they are almost always wrong. A typical scenario is; PM describes a feature, asks for an estimate, and the developer gives it to him, right then and there. What's wrong with that? The developer hasn't done any research or exploration into the problem at all, and has no idea what he's talking about.

When you think of a time estimate, you're going to come up with a time assuming that the problem can be solved in the most obvious way, and that's because we can't possibly know about the problems we don't know about. It's not a terrible crime to not know things you don't know, but it is bad to make time estimates on things we don't know.

The correct answer is "give me a few hours to a day to look into the problem and I'll let you know how long I think it will take". The amount of time it takes for discovery depends on how big the feature is of course, but the point is you need to get your feet wet to determine what unknowns there might be, and you shouldn't give an estimate until you have done that.