Q:

2D platformers: why make the physics dependent on the framerate?

"Super Meat Boy" is a difficult platformer that recently came out for PC, requiring exceptional control and pixel-perfect jumping. The physics code in the game is dependent on the framerate, which is locked to 60fps; this means that if your computer can't run the game at full speed, the physics will go insane, causing (among other things) your character to run slower and fall through the ground. Furthermore, if vsync is off, the game runs extremely fast.
Could those experienced with 2D game programming help explain why the game was coded this way? Wouldn't a physics loop running at a constant rate be a better solution? (Actually, I think a physics loop is used for parts of the game, since some of the entities continue to move normally regardless of the framerate. Your character, on the other hand, runs exactly [fps/60] as fast.)
What bothers me about this implementation is the loss of abstraction between the game engine and the graphics rendering, which depends on system-specific things like the monitor, graphics card, and CPU. If, for whatever reason, your computer can't handle vsync, or can't run the game at exactly 60fps, it'll break spectacularly. Why should the rendering step in any way influence the physics calculations? (Most games nowadays would either slow down the game or skip frames.) On the other hand, I understand that old-school platformers on the NES and SNES depended on a fixed framerate for much of their control and physics. Why is this, and would it be possible to create a patformer in that vein without having the framerate dependency? Is there necessarily a loss of precision if you separate the graphics rendering from the rest of the engine?
Thank you, and sorry if the question was confusing.

A:

Why?

Handful of reasons, take your pick: They didn't know any better.  .It's quicker and easier to implement.    They were focused more on the gameplay and less on the edge cases that might not crop up in most cases. 
You did a pretty good job of explaining why not.  I'm sure you've noticed there's lots of topics that cover the subject.  I'm not sure you'll find a satisfactory answer beyond the ones I listed.

A:

SMB was originally a console game where it's safe to assume that it's able to run at 60fps on all Xbox360s (well, maybe 50 for some PAL players). Assuming a fixed timestep simplifies the code a fair bit. 
Whilst it's easy to scale a lot of things by a variable timestep - 'pos += velocity * timestep', it gets quite tricky to do it correctly when you're dealing with accelerations, and rates of change of acceleration, and so on.
Decoupling gameplay and rendering is a nice solution in theory, but implementing it well (with good interpolation) is quite tricky, and things can easily get messy. It's fairly uncommon for this technique to be used in real games (although some big games do do it, particularly RTS games, but more for network game synchronization).
When also designing for a fixed screen resolution as well as a fixed framerate, there's one other thing you can do to make the scrolling extra smooth. You can ensure that the game scrolls at a whole number of pixels-per-frame - avoiding any 'subpixel wobble' you may get by scrolling a fractional number of pixels per frame. 

