Why keep ISR code terse?

Does this not defeat the purpose of interrupts, as the loop() is still polling the status bits?

Using an interrupt all but guarantees that your switch will be recognized, even if you wait to handle it a little later in loop(). Any flag/status bit you set in the interrupt routine can stay set when the physical switch changes its state, so it is still set when loop() gets around to checking it.

Polling a switch in loop(), on the other hand, depends on the switch still being set when the loop() logic gets around to checking it. Depending on how complex your logic is, and whether it contains any delays, the switch could be different by the time your logic gets to the part of the code that checks the pin state associated with that switch.

Remember to define the flag/status bit as volatile to tell the compiler's optimizer not to make any assumptions about it. Otherwise, the code generated by the compiler may not be effective.