Estimation is so ingrained in software development that it is just assumed that you will provide estimates for everything you do.
First point estimates are never treated as they should be i.e. guesses when provided. They are instead treated as promises and many times guarantees. This abuse of the word estimate and its purpose as a starting point of what is known at the time of the estimate, often this is given with the least amount of information and most uncertainty about a particular item. This leads to burn out and treatment of people and I emphasize to the full extent people as resources. Software is a communication system employed to run on hardware, but it is always just a form of communicate to others in a mostly organized manner a discrete set of information to another human. Treat otherwise and you fall into the commodization of labor and the mistreatment of people.
Second point and this is the more glaring of the issues with estimates is that they are almost always wrong. Why do you even want to estimate or waste your time in agile with things like planning poker, random units of point, etc. IT DOESN'T FUCKING MATTER. Sidenote agile is about challenging ingrained processes to see what works and don't. The history of software development so far has conclusively proved that estimates are not correct and don't work.
Humans are excellent at prioritizing things and we are terrible at guessing and estimating because we have implicit known biases. Humans evolved to judge a limited set of inputs in the fastest possible way for survival which means our brains are great at making a set of priorities and keeping that list short and actionable at any point right now, planning for the future not so well i.e. the ignoring of global warming.
This is why Kanban works so well. As it is a simple priority list that is max limited to state of the code buckets (development, test, deployment).
This brings me to the coalescing of these two points in that managers ask for estimates because they like to substitute them as promises and then they do a little resource manipulation which lets them gamble (and yes I said gamble, because that is what it is when you do fixed cost budgets) with other peoples times according to their priorities.
Example thought process: If I get these sets of estimates for this project can I gamble my subordinates time (and goddamn it programmers have a limited set of time because we are all going to die and as a "resource" we are expendable according to gambling management) according to the priority of which one will make me either look best or most money.
Fucking tired of it all. The best way is to stop playing the substitution game and go directly to what is important.
The priority of items and how to get them to customers. Everything else is substituting and gambling and the people who do it most are the ones who have the least to lose