”spinning on a fine-grained clock register until it reaches a predetermined value” would require a second thread to do that counting, and isn’t guaranteed to be constant time.
Also, even if it were, one probably could detect that the CPU was just spinning from a side channel, for example by tracking CPU sleep state, cache line pressure or contention for integer units in the CPU.
No; the core goal of side-channel-free algorithms (of which constant time algorithms are a subset) is that the instructions executed by the CPU should not depend on secret data.
Spinning until a fixed time is reached could conceivably leak information if another thread can time math-unit bandwidth; it would be able to distinguish the spinwait from bona-fide mathematical computation.
However, no (known) method accessible to code running on the machine can distinguish between an adder unit summing zeroes versus key data.
The first idea seems way easier to achieve and maintain. It can be implemented at higher level around a complex, lumped operation, like calculating a signature, without having to go into all of that operation's subroutines to change everything to constant time. We could conceivably drop it into any language, wrapping it around any crypto, while treating that as a black-box.
Could also be faster. That is to say, variable-time calculations likely have a worst case time that is better than for the equivalent fixed-time calculations, since we just write the obvious code for the CPU using its normal instructions and optimize as usual. If we are able to box the padded time fairly tightly to the worst case, we are better off performance-wise than with the fixed-time implementations.
Also, even if it were, one probably could detect that the CPU was just spinning from a side channel, for example by tracking CPU sleep state, cache line pressure or contention for integer units in the CPU.