Comment should be also updated.

Are you sure that CNTFREQ is always set up correctly?

The DT binding allows you to supply frequency counts from the DT timer node (using the clock-frequency property) and is still used for new SoCs -> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/exynos/exynos8895.dtsi#L459

A corrupted bootloader (in ROM or secure flash) is rare, but not that uncommon.

It will be less broken than it is currently. We don't know how long it takes to call a function 200 times in a loop as it depends on the cpu frequency and micro-architecture.

I disagree, while the original code may have caused a shorter than desired delay, the new code may do, at worst cause, something like a livelock. The CNTFREQ reset value is undefined, so new code with broken fw can cause anything from almost zero to extremely long delays.
It's hard to say which is worse.

However, we can easily work around this by trimming CNTFREQ to the range of expected values. With high probability, we can expect CNTFREQ to be greater than 10 MHz and less than (or equal to) 1 GHz (which is also required by v8.6). So if CNTFREQ is not in the above range, we can use 1 GHz.

The implementation is trivial and gives the safest result, IMHO.