> you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable.

It's not binary, it's a continuum.

With experience, it's possible to identify whether the new project or set of tasks is very similar to work done previously (possibly many times) or if it has substantial new territory with many unknowns.

The more similarity to past work, the higher the chance that reasonably accurate estimates can be created. More tasks in new territory increases unknowns and decreases estimate accuracy. Some people work in areas where new projects frequently are similar to previous projects, some people work in areas where that is not the case. I've worked in both.

Paying close attention to the patterns over the years and decades helps to improve the mapping of situation to estimate.

Yes, but where reliability is concerned, a continuum is a problem. You can't say with any certainty where any given thing is on the continuum, or even define its bounds.

This is exactly what makes estimates categorically unreliable. The ones that aren't accurate will surprise you and mess things up.

In that sense, it does compress to being binary. To have a whole organisation work on the premise that estimates are reliable, they all have to be, at least within some pretty tight error bound (a small number of inaccuracies can be absorbed, but at some point the premise becomes de facto negated by inaccuracies).