And even though it's "impossible", I and hundreds of my peers at work do it every week with a workable degree of accuracy, relative to company-wide work in progress.
In any case, the usual problems are:
1. We software developers think we're the first to face uncertainty, including massive uncertainty. We are not. We are in fact lightweights in this department. Ask a civil, structural or plant engineer for war stories. Or read Industrial Megaprojects to see how skipping a single water-temperature test cost billions of dollars.
2. We tend to embrace the nirvana fallacy. "Perfect or very accurate estimation is worthless; therefore, all estimation is worthless".
3. "Some projects are pure research". Yes. But very few. And even they contain bog-ordinary implementation details. Writing a fantastical new language? Well guess what: parsers have been written before, and someone with data or relevant experience could break down the task into subtasks and estimate them.
I think the real reason that we so dread estimates is:
1. They aren't treated as estimates. People turn them into deadlines. Or try to negotiate with the estimate. Which means they aren't estimates any more.
2. We get them wildly wrong the first few times and throw our hands in the air. Improving estimates is hard. If it were easy, we wouldn't need to consciously do it.