[MikeE]

We don't have any loops within the command or subsystem methods themselves (at least there are no occurrences of "for" or "while" in the code).

In our current version, CAN timeout exceptions are handled by marking a fault status on the subsystem. Fault status is reported every few iterations of {Auto|Teleop|Disabled}Periodic() to the SmartDashboard.
(A better approach would be to report changes in fault status only and do so immediately - we'll change the implementation soon.)
We do not attempt to re-transmit the CAN message, but we also don't disable the subsystem.

The only source of delays in the user code are the CAN operations themselves. There are a maximum of 4 CAN messages during the drive execute method - setX() on both drive motors and optionally configNeutralMode() if a button changes state.
Note that since we are running closed loop on the Jaguars we don't need to ask for encoder readings.

The worst case for any command method is 10 CAN messages to set up the drive closed loop for both motors and that happens only during the init() method once per teleop period.

Finally, thanks for the loop/delay suggestion. I can't find any likely culprits in the code, but I'll take a deeper dive.