Honestly? I don't think you can get an answer to this.
Estimation is an inherited practice from other businesses. Most businesses, it's relatively straightforward to estimate. How long will it take you to balance that ledger? About the same amount of time as the previous one, assuming no major mistakes or criminal acts have happened. How long to stack those boxes? How long to make those cakes?
Most creative occupations don't have this. A few do; if you're a professional writer taking up front distributions, you'll be asked for dates, by example. But all told, it is relatively rare for creatives to be deadlined, because it's so unreliable.
One major issue is that creative work is rarely collaborative-cumulative. There aren't many jobs in which one creative is stuck because the other creative isn't finished yet.
Collaborative jobs tend to want scheduling so that one staff member doesn't become overcommitted. It's relatively easy to understand at a lumber mill: you need one person doing center-sawing for every person doing bark shaving. If you have eight of the second job but only one of the first job, seven of your people will be generally idle.
Software has a core problem, in that pieces which are dependent on one another are difficult to schedule. There are very few processes that work this way, so society doesn't actually have very good norms for this.
At this point, opinions are going to split on how to interpret things.
Many people will say "well, someone has to schedule." This isn't actually the case, of course; I've been at software shops where the software is done when it's done, and everyone can basically screw off if they want to know more about what's ready next month. This is more common in SAAS shops than in traditional shops; SAAS shops don't usually advertise on next month's features, and don't have to encourage users to upgrade.
Many people, charging forwards assuming that the scheduling must occur, will say "well what, do you want it to be the managers?" And yes, I actually do. They do in every other industry. "But they're not doing the work!" I don't care. They don't do the work in any other industry. "But they don't know how long it's going to take!" Again, I do not care, because I don't either. To me, the entire reason this seems like a problem is punition.
"Is that even a word?" Yes; to leverage it is to be punitive. To punish.
Imagine, if you will, with me, a world where a manager is hired to be able to manage, rather than promoted out of being a good developer.
Imagine a world in which literally nobody is held to the estimates, so we don't have to pad them and juggle them and make them nonsensical to protect ourselves. They can just be best guesses.
Imagine a world where the estimates are made by a third party who's been watching you for a year, who is trained in statistical estimation techniques and is data driven.
Imagine a world where you didn't make the estimate, and if the estimate is wrong, nobody gives a shit. It was just an estimate.
You know what you just imagined? Every other job on Earth.
Go talk to a construction worker. Oh, the estimate was short a month. Are you doing overnights to get it in on time? Lol, no. What professional would do that?
Lawyers? Not unless a life was on the line.
Doctors? Not unless a life was on the line.
Actors? Not unless ten million dollars for them personally was on the line.
Who would do that for their regular salary?
Well, computer programmers. But that's because we've all been taught these nonsense rules by "senior" 19 year olds at their first job, and somehow, we've fallen for them.
These things are happening for one very simple reason. Just one, and only one.
Because you aren't saying "no."
It's very simple, it turns out. Go into that room with your head held high, and say "you know, the science says that making these estimates slows everything down, makes everyone unhappy, makes people make bad decisions on things that are little better than guesses, and drives your best programmers off of the team. FAANG hasn't done this for almost ten years. Smart bosses are moving past this."
Then just stop there, and wait for your boss to want to look smart.
Get one of your coworkers to do the same thing, three months from now.
It'll take six months.
Your boss doesn't want to do this either; they just think they have to, for the same reason that you do.
Lead them to Elysium. Freedom is possible.
There's a thing in psychology called the monkeys and the ladder. This is a real thing, and it's just one inch short of abusive to the animals, so it's hilarious.
Get five monkeys in a room. Put a ladder in the room. Put some awesome food at the top of the ladder.
Every time a monkey goes near the ladder, start yelling, from a safe place behind a fence or something (because monkeys will mess you up.)
If a monkey touches the ladder, hose it and all the other monkeys down. They don't like that, in the way that cats don't like that, and they will bail.
After a half hour of this, they will figure it out, and all the other monkeys will stop any given monkey from using the ladder.
Now, replace a monkey with a new monkey. They won't let the new monkey use the ladder. The new monkey will never see the hose.
On each following day, replace a monkey. A second. A third. A fourth, and now the fifth.
Now you've got a whole new team of monkeys. None of them have ever seen the hose. All the same, they won't let each other use the ladder.
This is your management team and its estimates.
Go use the ladder. They need to see that it's safe before their tiny simian brain can adjust.
Tell your management team that if they unburden one team from estimation for twelve months, that team will radically speed up, become happier, feel less scared, and produce more side projects.
Tell a manager who isn't the oldest, so they can ladder climb, but isn't the youngest, so they have some weight to swing around.
Why do we do this?
Because ladder tradition is hard to shake. Because few of us have the courage to just try going for the goddamned banana. Because we think in terms of what the previous monkeys insist on.
There is no good reason for programmers to estimate, and all the research science says that it's a terribly toxic and counterproductive pracice.
Beware any Lumbergh who patiently explains.