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.

How can terrain physics be handled when a lot of modern terrain rendering is done via the GPU?

Normally for brute force approach and small heightmaps you could create vertices on the CPU and load them into a physics engine as a collision mesh but with GPU approaches there isn't always a 1:1 mapping of vertex data on the CPU to whats displayed on screen (eg. hardware tessellation or vertex morphing). One idea was to generate a low-medium resolution version on the CPU to form the collision mesh but I'm not sure how practical this is as it may cause visual artifacts with physics objects sinking into the terrain or perhaps even floating.

What is the modern approach to this that games like BF3 are using?