1. JSperf doesn't encourage any kind of validation that the various snippets actually do the same thing. I'm not kidding when I say that almost all jsperfs I read are buggy. This one is too; it reuses the same pre-cached nodes without cloning them, and those aren't semantics you want and aren't comparable with innerHTML.
2. JSperf's scaling is terrible. It's showing ops/sec rather than sec/ops, when the latter is much more interesting. Almost always you're interested in keeping UI latency low, not in somehow repeating as many operations per second; the ops/sec display emphasizes tiny differences that don't matter over very large differences that do. A difference in 0.01s vs 0.011s will appear just as large as (say) 0.1s vs. 1s, and that's not helpful. A logarithmic scale might be nice too.
3. JSperf's semantics are surprising enough to cause bugs. For instance, the benchmark setup/teardown aren't called for every test, nor are they merely called before the first and after the last test - but something utterly useless in between. Tests aren't isolated from each other, so cruft left from one test can impact a later test easily. Actually, tests are run in the jsperf document itself, so trivial stuff like how many comments or versions a benchmark has could conceivably impact DOM performance.
It can still be a useful tool - but be aware that most jsperfs out there are quite misleading because they don't test what they claim.
http://jsperf.com/appendchild-vs-documentfragment-vs-innerht... (scroll down for the comparison chart!)