I maintain that presenting the use of nolock as a tuning tool is both dangerous and missleading.

That there is a use for read uncommitted I will agree in certain circumstances, and lets use isolation levels here to make sure everyone understands exactly what we're talking about, although I'd always prefer to lean towards read only databases or filegroups.  There's always going to be some gain if you tell sql server not to issue shared locks but compared to normal tuning and optimisation I think the risk outweighs any possible gains.

I also take exception to the phrase "Using hints in a query is something that most DBAs don't ever seem to bother with" - there's a REALLY REALLY good reason we generally don't - telling the optimiser that you know better is not recomended. I'd also be more interested if the tests had been run on a server rather than a laptop, I also note that your plans show parallelism, I suggest you try running your tests using profiler, IO stats often do not show additional io generated by parallel plans .. as I remarked first time around I tried a couple of simple tests on a server and could not see any difference.

I'd also question testing against table scans, this is something your average DBA tries to avoid.