The benefit of interrupts is that you maximize the amount of time your program does "doing work" rather than checking whether something has happened, and you minimize the latency in responding to the event (if you only check for a sensor value every 100ms, and the value changes 1ms into your waiting period, you are wasting 99ms).
The downside of interrupts is that they can happen at any time...if you have "real-time" code such as a PID loop, being interrupted at the wrong time can cause bad things to happen. It also means you need to be careful that your interrupt handler doesn't cause
data hazards...it shouldn't mess with any critical state that could cause your program to go off the rails when it returns to normal execution. Good interrupt handlers should also be very fast.
As a general rule of thumb, in FRC I usually poll my data (since it is simpler)...unless polling is too slow. For example, on the sensor we used to detect a ball ready to fire, polling in the main teleoperated loop (nominally 50Hz) is just fine. The ball moved at about 3 feet per second through our elevator, so if we're 1/50s late in responding to the sensor, the ball has only moved an additional 3/4"...not a big deal since the shooter wheels are several more inches away. When we used encoders with the old IFI control system, we used interrupts because missing a count would be disastrous (the cRIO does this with its FPGA, so now we simply poll the FPGA for the encoder count when we need it).