IMO this is also a better way to communicate with stakeholders outside the team instead of committing to a specific date. It gives more context and clearly communicates that this is a probability game after all since there are quite few moving variables.
The PMI project management methodology even pre-scribes this (after the project is over, to reflect, and then to gather collected learnings and objective stats so as to help better estimation of future projects), but the problem is many engineers see project management a administrative burden rather than as a tool, and they have a tinkerer's mind-set rather than a scientist's mind-set.
Good project management practice is also not to use point estimates but intervals: something is going to take "betweek [i;j] person days". PERT-estimates are even three-point estimates of work (best case, expected case, worst case), so you model the uncertainty explicitly rather than by some alchemist formula ("double and add 20%").
Incidentally, I found out empirically that the best technical people tend to be the worst at estimating their own time needed to complete a task. That's because the best are often also a bit over-confident, perhaps. Letting each team member estimate a task and adding a 20% correction for unforseen issues has worked well to make my projects be delivered on time.
Tip: Push back if management tells you how long you have; either explain to them what you can give to them in the time they dictate or reject their task order and say you will come back when you have calculated how long the project takes, which can only be rationally determined once the scope is clear(er).
Check out/google: PMI PMP methodology and also PMBOK (project management body of knowledge) > "Organizational Process Assets" (OPAs) > "Lessons Learned Repository"
How long does it take to learn to juggle 3 items? 4? 5?
How much time will it take you to measure the coast of England between Brighton and Seaton?