I saw elsewhere that you're defining estimating as a very detailed and involved process, which the author of the article did not, the person I originally claimed estimates are impossible did not, and I did not.
I agree that's not necessary in most cases, if not all, to do the level of estimating you described.
And you'll note that I didn't include "people who are doing me a favor" in the list of individuals I'd insist on an estimate from.
You don't sound like you're one of these people, but I personally feel that software developers who act like they're performing special incantations over their keyboard and can't be expected to answer to anyone about their deliverables do us all a disservice, though maybe I should just be happy that they allow me to provide an alternative that is much easier to work with and results in additional business for me.
And yes, I strongly believe in accountability to business stakeholders, customers, and colleagues. I just think the better way is not paper fantasies, but demonstrated realities. Focusing on working software, customer collaboration, and responding to change, one might say. But people have said it before and it didn't make much difference.
See "standard" vs. "schedule", and your very specific and formal definition of an estimate that is almost certainly not what anyone else has been using during this discussion and is not used in practice in most software development shops.
Kudos to you for delivering working features on a consistent enough basis that you've earned enough goodwill that people basically leave you to your internal processes and trust that you'll come through for them. I believe that's necessary to have a healthy working environment where you don't end up with what you, I, and every other software developer on earth is trying to avoid, which is an acrimonious relationship with the people with the money where they dictate what, where, when, and how we do our job.
But to claim that there is literally no estimating or scheduling taking place as you perform software development is just not true. You can post your disagreement on every single comment I've made on this topic if you want, your existing comments already speak for themselves on the matter.
If your point is that making things has a temporal reality to it, sure. But when people ask me for estimates, I give them two options: we start a formal estimation practice, where we do activities that produce what actual engineers would recognize as reliable numbers, or we do it kanban-style, which does not involve an estimation practice, but gives product stakeholders direct control over time/cost tradeoffs.
Some people, here and elsewhere, argue for a third option, which is going through various levels of rigamarole that gives horseshit numbers so that the more mendacious managers and executives can put on a performance of rigor while telling people with power what they want to hear. I refuse.
And I think it's that bucking the primate dominance hierarchy that makes people absolutely freak out when people talk about no-estimates approaches. Per POSIWID, the purpose of standard corporate "estimation" is not to produce reliable numbers. It's to avoid conflict. I get why people would rather freak out at me than make their bosses unhappy. But I would suggest that's a short-term gain for long-term pain. For organizations that want to actually get things done, hallucinatory project "plans" are bad for everybody. I think ultimately software engineering should be an actual profession. It's not looking great, but I live in hope.
That some random person on the internet who wouldn't have hired me anyhow will now not hire me is a blow I'll have to learn to live with. But I have literal decades of stakeholders happy working this way. One way that happens is that they pick a date and then we built what fits between now and then. So they get the date, but no promises about what will get delivered.
In practice people like this better because beyond a certain very coarse level, estimates are about feelings of engagement and control. What this approach gives them instead is not just feelings, but actual engagement and control. What they get from me is not some unreliable bullshit date, but a commitment to deliver useful things early and often, so that we can together discover something better than their initial visions.
And yes, of course I accept this from people who do work for me. My side hustle is starting a pinball museum. When volunteers take on repairing a just-arrived machine, I never ask them for estimates. I ask them to focus on doing it right. They discover problems, figure out how to fix them, and try it out to see if there are more problems. The work takes as long as it takes. Or I hired a friend to design the logo. I never asked for a date. We iterated on it, discovering an number of things along the way, including through user tests. It took a lot longer than I would have guessed, and that's great, because it turned out better than I could have hoped.
I understand that this is unfamiliar to people, and apparently it's quite upsetting. But I swear this works. There are more things, Horatio.