The whole game around estimates are a dirty way of dealing with other issues:

1) Can this be done before we run out of money and market opportunity?

2) How should other assets in the company be coordinated around the product. e.g. marketing needs a lead time to produce their campaign.

3) Scopeboxing.

For #1: If you work in a big-corp, this is tied explicitly to some project budget you have to manage. Going over that budget is a no-no. For startups, it's the investment dollars in the company. Startups tend to be over-capitalized for the products they tend to produce. Big-cos tend to under-fund in an attempt to capture as much of the money as profit (especially if your big-co is a contractor of some sort).

Estimates are intended to be converted into budget dollars (time * team-size * burn-rate) and are critically important signalling mechanisms. No money, no work.

For #2: Development is not the only piece of the puzzle. There might be a team just as large and much more expensive that relies on your estimate to get their work done so that the company runs in a reasonably coordinated fashion. "It'll get done when it gets done" doesn't allow anybody else in the universe to plan anything at all, and now the company has a bunch of expensive resources sitting around doing nothing until the primadona development team produces something. This is usually the source of adversarial and caustic inter-departmental relationships in a company.

For #3: Good development managers learn to invert the question of estimates. When asked "how long will this take to get done?" they answer with "how much time do we have? we can get this much done in that time" and then make that scope a commitment. This provides much more valuable information to corporate management, they get to set their schedule, but they also get to understand what the product they're going to be delivering is going to look like, which informs the teams from #2.

It also defines a clear barrier of what will be delivered and when. Scope creep gets cleanly pushed into "the next development phase" because anything that wasn't promised and agreed upon is outside of the current development phase. This approach lets the development manager set expectations, and also lets them never say "no". "Sure we can do that, I'll put that in the next development phase" becomes the answer. Phases should be scoped to deliver a completed working version of the product (as opposed to sprints which complete components of a product).

If the budget runs out, or a marketing campaign is underway and development is paused, the development manager now has a barrel full of things to scope out for the next development phase. Taking this time to work with corporate management and prioritize and scope out the next phase is usually a good idea. When the time comes to resume work, the development manager can again say "I'll deliver this much by this date".

Awesome development managers will underpromise on the scope and keep a reserve of features as a stretch goal. If they hit the major scope, they look like a competent and solid development team. If they hit the stretch goals they surprise and delight everybody else in the company.

I'm not saying it's easy, but it's better than a waterfall approach and what passes as Agile in most shops. It results in shipping products and allows development to be better determined into overall strategy. What corp management needs is predictability, not undetermined development cycles and feature creep.

(#4) - To be able to say "how much time do we have? we can get this much done in that time" the devmanager needs to actually know how to estimate. A good technique is to break the tasks down and ask the developer who's likely to do the coding how long they'd take, add up those times and see if they fit by the due date. If not, start tossing things. It's amazing how much you can cut from a product and still end up with an MVP or with another version phase.

(#5) - To do all this also requires the devmanager to understand what are the minimum tasks required to achieve a working product at the end of a phase. Those tasks are the core of the scope. Anything else is stretch. This usually means the devmanager needs to have a bit of domain expertise to figure this out. It should come as a surprise, just like soda execs shouldn't run Apple, devmanagers who don't understand what they're building shouldn't be building it.