"No, it's less effort than that"

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time, and that's how you end up with unrealistic estimations.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

I agree with all the points you've made, but I would add that the PMs and managers and directors and whatnot are never that keen to help engineers out on this front.

It is a rare person indeed that can do software development and think (and talk) in business terms. As a dev, being able to talk in business terms about the problems you face in creating software is really, really handy.

But I can count on one hand the number of POs, directors, managers that want to engage in that conversation with developers. Most of the time a solution is thrown over the wall and developers are told to build a thing.

An actual conversation about a business problem between the people that actually have the problem and the people that will build the software that (hopefully) solves it happens way, way less often than it should.