I have been pondering this for about 30 years, ever since I started writing software professionally.
Of course, the cart is always put before the horse. People ask "why is the project taking longer than it should", rather than "why was the time estimate wrong". For some reason, I guess because it comes first, the estimate is regarded as gospel truth, and if the actual work didn't match the estimate then it must be due to bad developers.
This despite the fact it is pretty generally known you can't predict the future. Software projects simply contain too many "unknown unknowns" to come up with accurate, detailed estimates.
I have noticed that the unknown unknowns all lead to more work required, there are vanishingly few times when it is unexpectedly discovered that less work is required. Even the known unknowns are badly accounted for, e.g. a study found developers only spent 50% of the time coding, even though they are nominally 100% on a project. The "lost time" is all the workplace overhead, like meetings, training, holidays, sickness, supporting legacy projects etc.
On the flip side, all the drivers from business management are the wrong way. i.e. they want less time, less cost, less resources. There is a strong tendency for them to refuse to listen to anything they don't want to hear. If they get an answer that doesn't fit, they ask again until they get an answer they like. Even if the developers are not "yes" men, the management will always take their most optimistic estimate.
It's a classic case where the "wisdom of crowds" breaks down, because there is a strong bias towards the "least cost" answer, rather than the median answer.
Unfortunately, I have come to the conclusion that the naive and ignorant people in charge always win the argument, so the industry will never improve.