Hard disagree. It's not hard to do well. The draw back is less than 1 frame of input latency. If your game uses a physics engine or is networked you are forced to use a constant update rate, ie: 30 or 60hz. The draw backs to linking the physics update rate to the monitor refresh rate are enormous and untenable in a networked game.
I don't personally care much about a frame or two of latency (some do though, and for some genres that'll be a big deal); however I care about animation smoothness. If the monitor refresh rate is 144Hz and physics tick rate is 60Hz, you'll need some form of interpolation, which is hard to do well especially since the refresh rate isn't a multiple of tick rate.
An 'animation' tick can be (and should be) disconnected from the physics 'tick'. Physics/game logic 'ticks' should use a constant time so the simulation is more predictable and stable, a 'animation tick' can be exactly what the monitor refresh rate is and thus doesnt need 'interpolation between ticks'.
It's important to be precise. The position of a small subset of the "objects" are determined by the physics engine. You might have a character with 100s of thousands of vertices, but only a single capsule is in the physics engine. The movement of the characters fingers is not determined by the physics system.
