I think author addressed that explicitly as valid and true software engineer perspective, right at beginning of the article; and explained that such software engineers, and products they build, then usually slot into larger company's ecosystem (as by strict math, most IT team members will work at a large company as opposed to a startup), full of people and leaders and departments and teams and project who have plans and deadlines and dependencies, which are also valid and true.

I've had either luck or misfortune to "flip a switch" from two decades of being a techie/architect, to being a mid-manager, on basically a specific date as opposed to over the years, due to project's needs; and it's like that B&W picture of two faces and one vase in middle. Both perspectives are true, even if opposing and contradictory.

Good business lead will understand software engineer's perspective - even if it's not their primary view of the world, they can squint and catch a glimpse as needed. Likewise for good software leads.

Obstinate unwillingness to see or ascribe merit to other perspectives puts a ceiling on everybody's progress.

> it's a guess and can never be anything but a guess

Of course it's a guess. The question is how to make more accurate guesses.

> The question is how to make more accurate guesses.

I think the question should be about how to maximize the net return on time dedicated to development, which may mean spending less time on (and investing less reliance on) estimates rather than expending unbounded effort improving the quality of estimates.

What's the value to Sales/Marketing/etc of knowing what's coming when? How do you estimate that? It's estimates all the way down!