Estimates themselves are relatively useless. But the process of estimating is extremely useful, in my experience.
If a junior engineer gives some hand-wavy estimate of a project, I always ask them to sit down for 30 minutes and break the project down into bite-sized concrete tasks. "Bite-sized" means they need to estimate the tasks at some level. This usually uncovers some unexpected ambiguity or open questions which we can work to resolve. At that point we can also search for long poles, parallelizable work, unnecessary work, conceptual misunderstandings, etc., and it makes it easier for other engineers to swarm if the project starts slipping too much.
I find the opposite. Take the hand wavy eatimate at face value and just move on, update it as you do the task and discover the reasons the estimate was bad.
The other failure mode, where the team spends time discussing every ticket, wasting N people’s time when only 1 or 2 people have the expertise on that topic to debate the estimate, is way worse. It wastes more time, makes people act petty about who is doing more fictitious Fibonacci units of work, bikeshed over meaningless things like if a ticket is a 3 or a 5, and can make work scoping way more antagonistic than it needs to be.
If a junior engineer gives some hand-wavy estimate of a project, I always ask them to sit down for 30 minutes and break the project down into bite-sized concrete tasks. "Bite-sized" means they need to estimate the tasks at some level. This usually uncovers some unexpected ambiguity or open questions which we can work to resolve. At that point we can also search for long poles, parallelizable work, unnecessary work, conceptual misunderstandings, etc., and it makes it easier for other engineers to swarm if the project starts slipping too much.