Well, a loop that busy-loops while waiting for the timer will waste time, but it will at least produce a delay time that is based on crystal frequencies and divider steps, instead of being totally dependent on the used compiler version or optimization settings.

For quite short delays (up to maybe 10-500ms depending on hw and type of application), a busy-loop polling a timer is very good.

For shorter delays, it's better to to use assembler instructions to crate an instruction chain of fixed time and then loop that instruction chain.

For super-short delays, a couple of inlined NOP is great. #ifdef can be used to control how many NOP to insert, to support compiling the source for multiple clock frequencies.

But for really long loops (and 100ms+ is often a really long loop for a processor), it is normally best to let a timer ISR tick time and then have a superloop react when the timer variable has reached zero. This allows the processor to perform other things - reading keyboard, updating display, scanning ADC, responding to serial data, ... - while waiting for the delay to time out.

The thing to not ever do is to write a random sequence of C statements, and then add/remote statements until a suitable delay time is found. Such delays will hurt alot when switching to a different processor or compiler, or accidentally change a project setting or some unrelated code. One specific thing about 8051 compilers is that they do a lot of magic internally just to overcome limitations with the architecture. So just adding/removing some variables or add/remove a function call somewhere else in the source code can greatly affect how the compiler converts auto variables into reused global variables. The end result can be quite big, even when the original change seems miniscule.

Embedded programming is about taking control. Not just of the external hardware but of the internal operation of the processor.