fixed timesteps allow easier reproduction of the results of the simulation
I can't think of any disadvantages of fixed timesteps. You mentioned something about using a fixed timestep masking problems, but I can't see that as a real problem. MrRowl, do you care to provide other disadvantages?
Here are some:
1. If you use a fixed physics timestep but a variable render frame time (or a render frame time that isn't a multiple of the physics timestep), but don't interpolate the physics results, then a smoothly moving physics object will not move smoothly across the screen, as sometimes it will experience N updates, and sometimes N+1 (for a fixed render frame time).
2. If you do interpolate between physics frames
2.1 that's an additional cost (which might be significant if you've got a lot of objects),
2.2 Also there's some "uncertainty" about where the object is - so when a user shoots an object, where is the impulse applied?
2.3 Debugging might be fun if your debug points etc don't match up with the interpolated object positions
2.4 If the ratio between the physics timestep and render timestep is such that sometimes you run 2 physics steps, and sometimes 1 (for example), and the physics simulation time is significant, then the frame rate can jitter from frame to frame (a lower, but rock steady, framerate is likely better than a high but variable framerate). If there's a spike in the render frame time (e.g. due to disk access), then a fixed physics timestep will result in a spike in the next
frame time etc.
3 If the game allows running in slow motion (bullet time) you need to handle at least two, possibly very different timesteps, and the transition between them, otherwise either (a) you always update at the normal timestep, and the effects of interpolation will become obvious, or (b) you always run at the reduced timestep, with a cost that's excessive when running at the normal rate.
In my current home project (a flight sim for mobile devices), a smaller timestep always results in better physics quality. I just clamp the frame time to a max value (something like 0.1s), and always use N physics steps per frame. The user can choose N as a simulation quality setting - it's always at least 3 (or so). This way I get a constant physics simulation cost, so a really steady frame rate (depending on other stuff!), and I can check that everything will at least remain stable at the the maximum physics step time (0.033s). Faster devices get slightly better physics quality. This was originally my quick placeholder before moving to fixed physics timestep and interpolation (which I've done before), but actually I think it works great so don't intend to change!
I know some big commerical games use fixed, and some variable physics timesteps. There are problems to solve whichever way you go!