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.
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.