The elephant in the room is this: a team can not produce good work without both competence and trust in equal measure. An immature engineer may assume a business stakeholder is dumb because they don't understand or engage on technical details, an immature business stakeholder may assume that pressure and threats can yield quality work. In both cases, the immature individuals are putting their energy into counter-productive hand-wringing.
But now here's where it gets hard: trust can't be blind and incompetence exists. The straw man analogy that content of estimates are somehow immutable and unavoidable facts like the weather demonstrates an incredible lack of agency and resourcefulness. We are talking about humans working together to solve problems and build things, we have incredible latitude on how we want to approach things. This viewpoint reeks of learned helplessness. Look at the proposed solutions:
> In these cases, discuss with your stakeholders: why the estimated effort is this much? what part of the story takes the most time? where are the biggest unknowns? In addition, discuss ways to: slice up the story and deliver it in multiple parts, validate each part early, preferably using prototypes
Do you see the assumed constraint? There is no discussion of the problem to be solved or job to be done. Often in these cases you have a non-technical person prescribing a solution that doesn't make sense. If that's the case, it can only be solved by an engineer who has communication skills and credibility to discuss a better approach to the problem. Assuming that a user story passed down to the team is somehow sacrosanct is the type of process-oriented dysfunction that tanks morale and leads to impotent teams.