It COULD, but it would be more trouble than it’s worth. For one thing, velocity and position aren’t directly related in all cases; take, for instance, situations where the player is running against a large wall. The engine will allow him to “move” without making any progress; he remains stationary, and the enemy remains shooting at a fixed point in space behind him? Or, for example, my player can grind if he makes contact with a specific spline-based rail actor; this actor moves him by updating his position to a new one on the spline every frame, not by applying velocity to his capsule. He moves FASTER along the rail than while walking, yet the enemy would nail every shot since he doesn’t actually have a VELOCITY, he’s just changing positions every tick.
For another thing, the VInterpTo node is just simpler. It’s very easy to set up and understand and doesn’t require a lot of math nodes for calculating things like which way to offset the aim position, how much to scale it by based on velocity, etc. The actor aims at a space which is always moving toward the player but cannot reach him unless he is stationary.