These are all valid points. I think this estimation technique does not apply to all projects, but I would like to offer the following feedback:

"When Dave says X, add 30%." Using the above methodology, the tasks are broken down to a reasonably fine granularity. You certainly want Dave's input, but basically, you run a report against the database and you see how long Dave took last time he did the same task.

Detailed time recorded in a database allows you to query estimated vs actual time, by person by task, so revisions to the estimation process can be made over time. It also helps when answering your question: "Am I more accurate when estimating some classes of tasks than others?" as you have metrics that will tell you. (I think this is why O'Connell feels that estimates based on past experience only works if you have hard data.)

RE: "Information gets extracted and shovelled into the gaping maw of Microsoft Project..." To be honest, I'm not a big fan of MS Project. It does help to get an overview of dependencies, and shows what tasks can be done in parallel with the available resources. But I find it unwieldy and cumbersome. So while we use it, it isn't the guiding tool in the project. (I also think that some project managers -- particlularly those who have fallen into the role from non-technical backgrounds -- use it as a crutch in lieu of actual project management. Hey, if you're fiddling with charts then you're justifying your income, right?)