Note that all the debates about timers are related to three things:
1) The issue of writing a delay in a high-level language, without "binding" the delay to something hardware-based, is that changes in the generated code can result in huge speed differences - all the way to the delay loop being totally removed. In this case, the delay is written in assembler, which means that it will only change speed if the core execution speed is changed (other clock frequency or switching between 12-clock, 6-clock, ...).

2) The use of a busy-loop means that the program will not do anything during the delay. So a running-light like this will spent almost 100% in a "dumb" delay. Use of timers and interrupts means that the code can do other background tasks while waiting for the delay time to end. In this case, there doesn't seem to be any other tasks to do for the processor so it doesn't matter if it busy-loops.

3) A busy-loop delay created without hardware feedback will slow down the delay. So you can't write a program with heavy interrupt use that will manage an exact software-only loop even if you write the loop in assembler. This isn't relevant here, since the delay isn't critical and the code isn't intended (what we can see) to be extended with any high-speed interrupt code.