A bad estimate is better than no estimates at all. There are plenty of empirical studies that prove that. Some computer scientists have a hard time dealing with non mathematical proofs. They have a huge blind spot for things like empirical case studies, qualitative studies, etc. Those are tools that people in other fields use when mathematical models fall short. There are not a lot of useful mathematical models you can use to model software development. So, understanding that software development is an inherently social process kind of points you in the direction of where to look for alternatives to that.
Humans are bad at estimating stuff. Software engineers doubly so. But even a bad estimate gives you some handle on how easy or hard something is to do. And you can break things down to improve the quality of the estimates. And then the rest is just using statistics to model the margins of error. Economists are very good at working with this sort of stuff. I always recommend people look at Don Reinertsen's work on lean development. He's using a lot of economical reasoning and notions such as cost of delay, amount of work in progress, and indeed cost estimates. Those being bad is less of an issue if you know they are only off by 2x vs. 10x. A 2x margin of error gives you some handle on the situation. A 10x uncertainty margin means you need to use some tricks to improve the quality. There are ways to do that. 2x is not great but is better than ignoring estimates.