Now Slashdot and ZDnet have weighed in, although for the most part they only are suggesting 50-100% performance hits. One good quote is:

It’s a lot easier to interfere with a moving head arm than it is to mess one up that’s locked on a track, so this isn’t surprising in the least for vibration to affect reads that require numerous long seeks. I’m surprised it’s not worse than they’ve found.

Moving the head requires accelerated head stepping to top speed, stepping to close to the track, slowing down, stopping at the destination track, waiting for the head to settle, and reading an address block to find out where you managed to land. If you find you missed the track, you have to go through the whole seek process again. (usually only once more, those short adjustment hops are pretty reliable because they’re lower speed) But that really hurts your single block read time.

Add to that the fact that the “high performance” drives are making more risky higher speed track changes, which increase the odds of missing your target and make the operation more sensitive to vibration. I’ve written direct HDD io code before, and sure, you can up the step speed to get very nice seek time boosts, but then you start missing your track and start getting reseeks. Usually you go with the fastest that’s acceptably reliable, and that puts you on the bleeding edge of having problems, where things like vibration can run you off the deep end of the bell curve.