sorry, i misspoke above. ui.background puts everything on one thread, queued up by the order of background calls. ui.delay does kick off independant threads, though these may still be shared or managed somehow with the ui system, but I am not sure. ui.delay seems like a fine approach for updating a label with current time.
I would avoid doing anything really time critical using ui.in_background. It is good when you want to ensure the calls are executed in the order they were called, but if you are having some sort of autonomous code that is not triggered by a ui action, a Thread might be better. I think i posted an async_exec decorator somewhere on the forum which is a Thread version of ui.in_background.
Phuket2 offers good advice about using cancel_delays -- you need a way for the loop to cancel. Checking on_screen may be a good approach, you could also set a stop flag, etc. Cancel_delays is useful when you have longish delays, though in your case, you probably would never be able to catch that 0.001 between calls, so you need something inside crazyCounter() to prevent kicking off the ui.delay. Another heavy handed approach would be to redefine crazyCounter in -- your stop or will_close method, that way you don't incur the overhead of checking a flag inside your crazyCounter(), which I gather you want to run as fast as possible.