My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.
However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine.
Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.
I've been on teams where estimation is easy - you've got years of roughly the same set of devs doing fairly similar feature/bug work on the same code base to look back on and give an educated guess on sizing. Right now I'm on a team that's mostly doing integrations with third-party systems where our skill levels on the team vary between 20 years and 6 months of experience in the field, let alone this team.
Software isn't the making of a thing, it's the designing of a thing.
Ask an architect how long it will take for them to design your dream home.
Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes.
Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.
Of course they do: people, furniture, water, air, heat.
If programming indeed was "usually" like that, then there shouldn't be much software getting produced at all. Since building "a new type of interdimensional alien spacecraft engine" is something that's very very unusual, to say the least. :)
The problem is I see estimates like this;
$COMPLEX_REQUIREMENT: 12 days BACK END - 3 days FRONT END - 3 days UNIT TEST - 2 days
...
Which is almost certainly gonna be wrong, so it useless. But "12" is a number and number can be added.
We have 274 man days this quarter, and of course we allow time for bugs and leave and stuff, so sum of estimates is 263, so that's our plan for the next 3 months.
Never works.
Estimates are useful for making branch decisions though.
So knowing is it 1 hour or 1 day or 1 week or 1 month or 1 year (which is closest) is useful for deciding if it is done (hint if it involves code at all then not 1 hour!)
For each category, accept it might take up to 5 times as long. So 1 day = 1 to 5 days. 1 week = 1 to 5 weeks and so on.
Is it a disaster if the thing took 5 weeks?
Id there another "1 week" tasks that is more urgent than the one you are thinking of doing next?
That is the level.
Then don't track too closely how long it takes .. BUT ... maybe have a team leader flag at 2.5x estimate to discuss in depth if it is worth carrying on. In addition to standups/whatever to get unblocked or report the estimate was way off.
In a nutshell treat the estimate as a decision heuristic. But not as a developer skill measurement tool, or a timeline delivery.
If you have a real deadline, then presumably you agreed to it (some contract) and hopefully when coming to that agreement technical people were consulted, and loads and loads of buffer was included. It is like agreeing to host people on Christmas day - it will probably need say 20 hours of prep, but arranging it 3 months ahead of time and slowly working on it the whole time is a surefire way of success. Starting the project on 23rd Dec is a surefire way to fail. Common sense in real life (because we use common sense not trying to "optimise" every last second).
Also in real life if other things mean you can't host Christmas ... you don't agree to the deadline. Let's book a table at the pub. That is what you do. Companies tend not to do that, they agree to all kinds of silly things. And you get silly deadlines, and bullshit estimates as a result.