There is Nothing so Practical as a Good Theory
This quote comes from the German-American social psychologist Kurt Lewin (1890-1947), who was pointing out that psychology was thin on good theories, but benefited greatly when there was one. A good theory simplifies explanations and makes them more coherent, robust, objective, and even allows better predictions of behavior.
So what's the theory - Principle - of making decisions in the presence of uncertainty without estimating the impact of those decisions? So far haven't heard one that could be tested outside of personal anecdotes 0f it works for me, so it must work for you.
The real problem that was brought to light by Woody's Zuill's original post way back when is quite simple
Estimates are misused by bad management to hold people accountable for things can never be accountable for. But it's not the estimate or the estimating process that is the root cause. It's the bad management.
But conjecturing - and it's pure conjecture - that Not Estimating is the corrective action for that Root Cause of dysfunctional management is essentially nonsense. First the dysfunction is behavioral - Bad Managers. Not mathematical - estimates made in the presence of underlying certainty.
Yes estimates are sometimes harder. Much too hard for those who have no experience making estimates. Even much harder when the customer is clueless about what she actually wants to spend her money on. So as Capers Jones says below, if our customer can't come up with some form of needed capabilities in exchange for the money being spent - we don't know how much or when we'll be done.
And if the customer puts an upper bound - a Not To Exceed contract we call that - on the spend, it doesn't remove the other two random variables from the work effort - Time and Capabilities. If the customer doesn't have some notion of What Done Looks Like - and not the lame definition of done found in the agile literature - but the real definition of done in units of measure of effectiveness, measures of performance, and all the ...ilities associated with the work outcomes - then you're on a DEATH MARCH project and estimating or not estimating isn't going to add one iota of increased probability of success.
Here's an example of a VERY software intensive system of systems A consistent multi-user, multi-goal framework for assessing system performance with application to a sonar system. This is not likely a system you will have worked on. But it is similar most all other Software Intensive System of Systems found in Enterprise IT.
But Jones's quote again fits a very broad set of domains - all domains I'd suggest.
