I also described something analogous to the above "displacement aware skinning" -- allowing your visual representation to move itself slightly more out of sync with the physics representation in order to become visually plausible.
This is what Hodgman is saying... live with approximations. And I agree with him.
With the usual method, the physics and graphics are out of sync slightly (with e.g. players feet hovering slightly, or penetrating the ground slightly). The above hack of moving the players feet to match the graphics representation is just a method to cover up the slight visual errors arising from the necessary approximations. It's not a general solution that you should implement in every possible circumstance.
I dont understand why you're having a problem with this -- you're describing and agreeing that graphics and physics are necessarily slightly out of sync in a typical game, and the above suggestion is a hack that makes the results visually plausible, while introducing out-of-sync problems elsewhere instead. It's just a shifting around of our approximations. It's just another option to add to your toolbox, to be evaluated on a case-by-case basis.
e.g. if the graphics engine moves a characters feet using IK so they don't penetrate the floor, then now their visual representation is slightly out of sync with the game's hit-boxes, so if you shoot a character in the foot, you might actually miss. Any hack like this can only be evaluated on a case-by-case basis. This might be of the greatest importance for some games (e.g. where realistic graphics without cliipping is important), and it might have terrible consequences for other games (e.g. where perfect hit-detection is important).
As another example; Bungie has particle systems that perform collision detection against the z-buffer, which has serious implications: if a surface isn't visible, then it's not collidable. If a particle is off-screen, it can't collide with anything. No read-back system is mentioned, so the particles can't interact with gameplay. etc, etc...
So, you don't simply just throw this idea out because it's useless for most cases... you add it to your tool-box in case you ever need to simulate a large number of short-lived, non-gameplay particles that only need visually-plausible collisions while on-screen -- such as sparks from gunshots, etc...