Just a quick note.

Variables shared between an ISR and the main application should be specified volatile, to order the compiler to not cache them.

Another thing - the timer variables are larger than one byte which means that an 8-bit processor is not guaranteed to read them atomically. This can lead to problems when the ISR is decrementing them while you at the same time test if any of them is expired.

If the variable has the value 0x0100, the compiler could pick up the low byte and see that it is zero. Then the ISR could come in and decrement the value to 0x00ff. After the ISR, the generated code could pick up the high byte and check if this one is zero. So depending on which byte order the compiler selects when checking for zero, the application could time out a timer with 255 ticks left.

Another thing here is that since you count down to zero and then assign new values - and turn off the reload interrupt when updating a timer - this solution will not allow the creation of a loop that runs at a fixed frequency. There is always the possibility of a slow time creep, where a 100ms delay may actually become 100, 100, 101, 100, 101, 100, 101, ...

On one hand, I prefer a solution that never ever stops the timer ISR.

On the other hand, timers are scarce, so I think you should do more with your ISR. At the very least, you should let the ISR increment a global "uptime" variable every ms. Possibly also a 1s variable every 1000 interrupts. This would allow your main loop to create long (and exact) delays or to keep track of time.