Variable timesteps exist to compensate for the finite and variable execution speed that (current) computers have. If you put everything into fixed timesteps, in most computers you will either have everything running slower than expected, and/or you will see jerky animations.
Variable timesteps compensate for timing differences, and prevents that. If the game loop is running too slow, it compensates moving more. If the loop is too fast, it moves less. When framerate variates, it does a good job keeping everything as smooth as possible.
Fixed timesteps are generally used for physics, but most of the time people will run physics in much lower framerates, because if we try to run lets say, physics + everything else @ 60fps, most computers won't be able to keep the pace, so it's common to separate both: physics running at low fixed framerate, everything else at variable maximum framerate.
And even the fixed timesteps will probably be adjusted down when the hardware cannot keep the pace. How else could we (today) be sure that the user's computer will have enough CPU to keep the pace? We cannot simply tell "run this in fullhd at 60fps" and it magically obeys, it needs enough processing power to do that, and for most games it won't.
Ok, so there is also the option of calling the update more than one time to try to keep the pace, but then I would call this "variable" as well, not "fixed", as it variates update rate by the elapsed time. That is, when physics is becoming behind, we call it more than one time to keep pace. I did use this solution one time, and it worked well. But I called that variable then, not fixed.