[Mark McLeod]

For the main drive motors we use the same as everyone should, 50Hz, to match the packet rate from the Driver Station. So the robot responds and makes changes when commands can change, as quickly as it should. If your Telop is quick and light, and you aren't pushing the cRIO limits elsewhere, then the Safety vi's are probably okay.
For most drive systems, especially at the low average speeds we tend to experience and the inertia in the system, applying the PID results any faster probably isn't necessary.
Take advantage of the high speed FPGA capabilities to accumulate sensor readings and just sample them when necessary. That kind of stuff.

Where we save the most is probably in processing sequenced actions or revisiting sensor readings.
Or matching the revisit time of actions to the real motor or mechanism response. There are a lot of actions that really don't happen that quickly. Window motors don't tend to get away from you. For instance, calculate how far a window motor powered mechanism will travel in 10ms and decide if you really need to know that fast or if you can slack off a bit in favor of a higher revisit rate for your 2000rpm CIM-powered flywheel.

Do you need to react to the push of a button within 10ms or is 100ms enough to match human responses?
Limit switches you probably want to be quicker on, but a button that makes LEDs on your robot flash can usually wait half a second to be checked.
A lot of cRIO time can get wasted just constantly checking a control that gets used maybe twice in two minutes.

Think in terms of software design tradeoffs.
Some things have to be 50Hz, for others 10Hz is plenty.