> I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates

I have the same anecdotal experience with a possible explanation:

Inexperienced engineers often don't see the greater picture or the kind of edge cases that will probably need to be handled ahead of time. I've often had the following type of conversation:

Engineer: "I think that would be a day's work"

Me: "This will need to interact with team X's package. Have you accounted for time spent interacting with them?"

Engineer: "Oh no, I guess two days then"

Me: "Will this account for edge case 1 and 2?"

Engineer: "Ah yes, I guess it would be three days then"

Me: "Testing?"

Engineer: "Maybe let's say a week?"

On the other hand experienced devs might have their judgement clouded by past events:

"Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue

> "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue

This is software though, if X has actually been done before then it doesn't need to be done again. It is already done.

Task X clearly had the potential to blow out by 3 months, and they are now working on task Y that is similar to X. It is a reasonable position to assume that there are other as-yet-unknown issues that might cause it to blow out by 3 months until someone has demonstrated that all the unknown unknowns are also resolved by doing it quickly. That is just basic evidence based planning.