> Can a team discover patterns in the things they
> underestimate?

If you do almost the same project twice, definitely. If you are doing different projects of a similar nature all the time, you can at least get an idea of the risk to the schedule and of systemic biases in estimation (i.e. the statistical distribution of time taken to complete a task / work package as a function of the initial estimate).

> Can a team do better by not estimating?
> Can a business do better by not estimating?

One of the goals of project management is to ensure that organisations don't start projects that do not have a valid business case (and cancels them as soon as it becomes clear that they don't); to work out if a project has a business case, it is necessary to estimate the benefits they project will bring to the organisation, and the costs and risks of the project. Businesses that can't do at least some basic form of cost-benefit analysis will likely end up going out of business under a series of projects that don't make financial sense.

The biggest win-win is to take an agile approach; instead of taking on a massive project which is hard to estimate, planning it up front, and deploying it in a big bang (the waterfall method), break it up into smaller iterations, each of which immediately delivers benefit to the organisation. Smaller projects are much easier to estimate, and if the organisation doesn't have the cash flow to continue after one iteration, they still get the benefit of the first iteration. The second iteration is only planned near the end of the first iteration, and so knowledge from the first iteration goes into the planning of the second, again making estimates more accurate.

> What are the axes along which scope can be cut?

When looking at a project, you have to look at all six variables at the same time: time, scope, cost, risk, benefit, and quality. If you want to cut the time / cost / risk, you might cut the scope, but that is likely to have implications for the quality and benefits. To assess whether a reduced scope makes sense, you need to look at the estimated effect that has on the benefits for the organisation - if cutting the scope leaves the project with no meaningful benefits for the organisation, because the products are unusable, but it still has some cost, then cutting the scope is not worthwhile. If cutting the scope reduces the cost and risk significantly, but still delivers most of the benefits, then it is probably worth it.

Delivering a project in iterations does have some overhead costs (and sometimes risks due to the rapid pace of change), so it ultimately comes down to a trade-off between iterating fast enough to manage the estimation risk but not so fast that it causes new problems - and that trade off is going to depend on external factors like the culture of the organsiation.

> What emotional needs keep stakeholders from cutting scope?

Often, stakeholders don't know much about software project management, and I think the application of the waterfall method, creating projects with huge scope, is applied because senior management wrongly believe that it is the best way to manage risks.

Up-front planning of large projects works very well on other types of projects with lower levels of uncertainty (for example, when constructing a large and complex building that could take hundreds of human years, up front planning probably works much better than agile approaches), and so managers apply what they know and insist that software projects be planned out from start to finish with full scope.