"Estimating work and committing to those estimates"
I agree with you that estimation has value, especially at the large scale when you are trying to budget for a multi-year project. (and at that level- the detail you think should be there simply isn't) You are also right that at some level it is a social problem, estimates and commitments are two very different things- and you don't just commit to an estimate. Estimates are predictions, statements of probability about the unknown future, hopefully based on solid data from past performance and some understanding of the work to be done. Commitments are promises to make things happen that are only partially within one's control. In many cases, an estimate is needed prior to getting the level of information that one would need to make a truly accurate prediction, so we respond with a range of dates to reflect that uncertainty, but this can be too early to make any kind of commitment.
If you estimate at the point in time where you are 50% likely to get the job done, and commit to that, half of the time you will be late, even though it is "average time" it would take to do that work. You can't take the easy way out and commit at 100% likely time, because you could be sick in the hospital tomorrow (and with a big enough project, someone eventually is). If you commit to an 90% confidence estimate, you get stuck with Parkinson's law type problems. Not to mention that those predictions with percentages are hard to base on real data...but if you make enough of them, you can actually get feedback on your accuracy.
The problem is that most audiences for estimates aren't able to deal with the uncertainty, and many givers of estimates are easily pushed into overcommitting. This is why some of the ideas popularized by the Agile movement seem to work- if you fix the time increment, it is much easier to flex on the scope, especially when it is not possible for it to be well-defined in advance. For example, there are many cases where an high confidence estimate can't be made- as is often the case in more research oriented projects, where the path to a working solution, or whether one will even be found, is unknown, and it is part of the job of the project to discover that. You are stuck with estimating how long it will take you to try approaches x, y, and z.
McConnell's classic "Software Estimation" probably says it better. See ch 1 of McConnell's book here- page one is on the commitment/target/estimation problem: http://www.stevemcconnell.com/estimation-01.pdf