Where did I say it was bad practice to reload TH0 without turning off interrupts?

I did suggest that was was atomicity problems in this code. The effect of this would be transient and probably not noticed by a human, however good programming practice would suggest that the possibility of these issues are avoided.

In the code snippet you posted, the problem I refer to is not to do with the interrupt code but with the main line code. Say you want to evaluate an alarm - you need to test hours and minutes and maybe seconds. Say you read the hours value and test that, then before you get to read the minutes value the interrupt code has kicked in and rolled over the hours - your test for time has just failed. And fail it will - probably in 1 in a million tests. In this instance I would suggest that one turns off the interrupts, copies the time values into another set of variables, then re-enable interrupts. The alarm test can then be safely done on the copied variables.

Interrupts are a double edged sword. It seems unresaonable not to use them but they introduce asynchronism into the code (by design) - the problem is how do you prove in all instances that you code will behave in the manner that is intended? It is possible to simulate with one interrupt source, but the combinations rapidly increase once you get more than one interrupt source. So good practice is to minimise your interrupt sources where possible and be aware of atomicity issues. Most RTOS' provide variable sharing mechanisms for this very reason.

Do-while Jones wrote a compelling article about the reasons NOT to use an interrupt!

Also http://www.ganssle.com/articles/acodeisr.htm