There is some level of estimation that we would do even if we were told not to. We always choose what to work on or what to push back on based on some idea of the time it would take. With very rare exceptions, you will usually have some idea of the size of a feature, at least order of magnitude.
Taking it to the absurd, if I asked you to add feature A (say, showing the current date and time in the UI) to your product, I doubt you would say 'it could take me 10 minutes, it could take me 10 years'. You will have some better idea of the size. You will sometimes be wrong about the work needed (oh, it turns out that our hardware clocks are bad and we can't rely on them, we need to change the clocks in the whole line, add another year to my estimate), but that is not going to be the most common occurrence, and so you will usually be roughly right, but only up to something like 4-10x (one day estimate - > 1-10 days; 1 month estimate - > 1-10 months).
The problem is when someone takes all these rough estimates and wants to add them up to divine a release date. Of course, they don't want to go with the honest estimate of '5 months - 4 years', so they tend to average it, and treat the 10x as a 'worse case scenario ', when it is just uncertainty in the estimation. So, they end up with something like '8 months to 1 year', which rarely works out in practice.
In the happy case though, the original estimates still come in handy later when it is time to drop features. 'we' re months out from the deadline, this feature was estimated at 1.5 months, and those 7 other features at 2 weeks each; let's cut the 1.5 month feature, it will not fit anyway', which is a pretty good use of that estimate.
Taking it to the absurd, if I asked you to add feature A (say, showing the current date and time in the UI) to your product, I doubt you would say 'it could take me 10 minutes, it could take me 10 years'. You will have some better idea of the size. You will sometimes be wrong about the work needed (oh, it turns out that our hardware clocks are bad and we can't rely on them, we need to change the clocks in the whole line, add another year to my estimate), but that is not going to be the most common occurrence, and so you will usually be roughly right, but only up to something like 4-10x (one day estimate - > 1-10 days; 1 month estimate - > 1-10 months).
The problem is when someone takes all these rough estimates and wants to add them up to divine a release date. Of course, they don't want to go with the honest estimate of '5 months - 4 years', so they tend to average it, and treat the 10x as a 'worse case scenario ', when it is just uncertainty in the estimation. So, they end up with something like '8 months to 1 year', which rarely works out in practice.
In the happy case though, the original estimates still come in handy later when it is time to drop features. 'we' re months out from the deadline, this feature was estimated at 1.5 months, and those 7 other features at 2 weeks each; let's cut the 1.5 month feature, it will not fit anyway', which is a pretty good use of that estimate.