Game dev here. Hardly any serious game developer uses lerp like that. I prefer a quadratic friction when I write custom friction, ie: a constant force away from velocity, and simply ensure it doesn't go past the zero point. More controllable. Box2Ds friction uses something like v = v * 1/(1+damping*delta_time), which is a good method as well.
Keep in mind it's best practice to run your game logic at a constant update rate and render an interpolated state between the current and previous game logic frame, meaning that if your game logic is frame rate dependent, you can still run it smoothly on any monitor.
Extrapolation isnt worth the chance of misprediction if it's a player movement based game.
The 'input latency' introduced by interpolating between frames is far different than typical 'input latency'. It's less than a single frame, and the game still renders movement at the same frame, just less movement. Most 'input latency' tests only test for _any_ movement, so those kinds of tests would detect 0 difference between 'interpolation', 'extrapolation' and 'render the exact game state'.
I'm a fast paced gamer, and I make fast paced games, I've never once 'felt' the input latency from interpolating the players position between simulation frames.
Technically, 'yes', but with huge caveats. You will still show player movement at the same 'latency', just _less than a full simulation frames worth_.
The benefits _far_ outweigh the costs of the other options. Games look _horrible_ if you render the physics at a different frame rate than the rest of the game. Like, horridly bad.
Keep in mind it's best practice to run your game logic at a constant update rate and render an interpolated state between the current and previous game logic frame, meaning that if your game logic is frame rate dependent, you can still run it smoothly on any monitor.