Absolute estimates [almost] always fail.

Relative estimates (e.g. story points expressed as Fibonnaci numbers, t-shirt sizing, etc) can be much more reliable, but they intentionally remove the direct relationship with duration since duration is expressed in absolute terms.

There is good and bad potential in both approaches, but one of the good things that can result from relative estimation (done correctly and consistently) is that the business is held accountable for prioritization and direction changes.

I've been part of (and sometimes led) teams that have estimated and delivered consistently, some using absolute and some using relative estimation. It's difficult but not impossible.

I've definitely been drug behind the UI/UX bus before. Dependence on other teams, who don't necessarily "get" that the perfect is in fact the enemy of the good, can be a huge factor.

Incomplete requirements is definitely a scourge.

Technical difficulties and unforeseen circumstances can and do definitely jump out of the weeds to get us.

But that's why we make the big bucks, yeah?

In my experience (25+ years and counting), relative estimation, iteration, delivering working software frequently WITHIN the context of an overall vision and architecture (as defined here: https://frickingruvin.medium.com/defining-architecture-edcb334d5cbb), and clear communication and negotiation with the business is a better way and our best hope so far for predictable software delivery.