The point I was trying to make was that not all frames take the same
amount of time to do the work to get to the screen. Like lets say a
comp can only manage an average of 20 fps, or on average it takes 50ms
per frame. Well it won't come out as 50ms per frame. It's likely to
occasionally come out so some frames have 200ms between them, and some
much less (lets say 25ms)
So if you decouple the updates and draws, and then make the updates
consistent with time, it means when you get the 200ms frame drawn, you
can do 4 updates next time, so that it isn't like time stopped. So if
the player was expecting to move a certain distance for a given amount
of time (say they are running to a ledge edge to jump) then they will
move at the rate they expected. If on the other hand you didn't do
updates to catch up to real world time, then the player may
accidentally jump early and not make the gap.
There are practical limits to it, like Ethan points out though. You
wouldn't want any significant amount of gameplay to go by without
feedback. If the computer can't make draws fast enough for some min
rate (for me 10fps or just 100ms between frames) than I have the
update rate slow down in real world time (you do that by limiting the
max number of updates between draws) so huge hiccups don't cause big
jumps in the world state with no feedback.
Basically the whole approach is about being able to have soft limits -
or as a game designer to be able to have more control about how the
gameplay goes on a wide range of computers. Some people like to know
the game can run up to 60 fps all the way down to 5fps where the
objects and controls all run at the same rate. But I think even if you
only allow 24fps to 12fps it's still worth it to smooth out bumps and
hiccups.