Update frequency limits your top speed, but sensor noise (encoder and current sensors) is usually the limiting factor for how fast the PIDs can respond to changes.
The Sensor class has a variable min_elapsed_time to limit how often the velocity gets recalculated (default 1 millisecond) to reduce the effect of angle noise. Then velocity gets lowpass filtered by the motor class, which further reduces noise but also reduces how quickly the PID can respond to changes in speed. The default time constant is 5 milliseconds. Then the current sense is also lowpass filtered with default 5ms, which I think means there will be a 10ms delay between measuring the speed and applying torque in response. There’s an optional lowpass for the angle too, but it’s disabled by default.
The defaults are chosen to give decent results for beginners on a variety of hardware, not for maximum performance. With good hardware, you can use lower filter constants.
Antun did some testing of INA240 versus AS712 a while back, and got much better results with the INA240. And presumably that was taking one sample per update, so it should be even better with oversampling. Maybe good enough to eliminate the need for lowpass filtering entirely on the current. Of course the shunts would need to be much lower resistance for high current motors, but should be able to get the same precision proportional to the overall range.
Another thing that’s been on my agenda for a long time is to combine the voltage-based current control with hardware current sense. I think that would be considered feed-forward. Predict the necessary voltage so it responds faster, but use measurement and PID to correct the error so it doesn’t explode if you guess wrong.