Actually it’s the other way around - variable timestep means the game simulation isn’t ‘deterministic’; this means it’ll be slightly different every time, for every player. So in a multiplayer game, it’ll go out of sync quickly if you use a variable timestep. However, in a purely single player game variable timesteps can make the game look smoother, and they have the advantage that on very weak systems (that can only run your game at 10-15fps or so) the game will still be pretty playable (albeit choppy looking).
Fixed timesteps are accurate all the time as every ‘step’/frame is processed no matter what and everything is guaranteed to move a specific amount every step, rather than some multiple of the elapsed time. However, if the game starts lagging, we need to run extra frames to keep up - assuming the rendering is what is causing the slowdown, this is fine… but if not, this will actually make the problem worse and crash the game. So systems that can only run the game at 10-15fps… will now not be able to run the game at all.
However, this is largely academic these days as most target computers will be fine running almost anything you throw at them; stick with a fixed timestep. Mobile devices are the only place where this is a different scenario - if you have plans to port to mobile then consider using a variable timestep from the get-go (and also check out Stage3DPunk!).
Also note that unless you multiply all movement code by FP.elapsed, there is NO advantage in using a variable timestep. In fact, all that will achieve is that your gameplay will be slower for people who cannot run your game at full speed - the worst of all scenarios. Make sure all your positional movement, rotations and physics are multiplied by the elapsed time!