The only consistently accurate estimates are based on previous work for which you have data. As a general rule, if you did X and it took Y days, the next time you do something similar to X, it will take an amount of time very similar to Y.

The problem is that (a) most organizations don't track and record the time to do anything and (b) people don't want to take the time to break down tasks to units similar to something they did before. Estimation is itself a time-consuming task.

Agree, splitting up tasks and writing all out to a T and then estimating it, could take basically all time or budget available for project.

Doesn't take anywhere near that long, but if you want accuracy, then you have to put in the work.

The easiest way is through ridiculous padding. If you consider carefully and think it will take a day, say it will take two weeks. If two weeks, say six months and so on.

This is the sort of thing you do when the unthinkable outcome shifts from idle workers to late delivery: Today, it's unthinkable to management for workers to be idle. If instead it were unthinkable for the project to be late, they would have to accept some risk of idleness to create that outcome.

Of course, you can always start doing prep work to de-risk the project, such as spikes, POCs, et cetera, within the planning phase. This might allow you to pad less but retain the certainty of your outcome.

Just an intuition developed over time with experience I suppose, as long as you have a fixed team you've worked with for a while on similar projects, with requirements that don't depend on many external factors.