The example you give (1 pixel of movement per frame) is the only case in which there is no difference. Anything faster or slower will show smoother movement by using all the available hardware pixels.

In my example, the larger screen has e.g. 8 times the number of pixels horizontally to show movement in. Instead of waiting 8 frames and skipping ahead 8 hardware-pixels, you can render the sprite 1 hardware-pixel further along every frame.

I still don't follow why you're saying "waiting 8 frames". But I think I get what you're talking about -- essentially interpolation.

The problem would come from anything other than simple movement of a static sprite. If there's some much as a wispy smoke trail animation off the back end of the rocket as it flies through the air, the sprite data isn't going to give you any indication where those particles should be waving about during your interpolated frames.

You'd model the rocket exhaust as individual particles or suffer the blocky animation. But it's not rocket science :)

'Realm of the Mad God' works this way, with the added affront to purity of having rotated pixels. I think it works rather well: http://www.youtube.com/watch?v=hpMdFFxFbY4