Long ago (I first remember doing it in about 1985 with the original Mac watch cursor) this was the standard way to do spinners: somewhere in your processing you incremented the spinner. It was hard to put the increments in the right places to keep the spinner going even when progress was happening, and nearly impossible to make it animate smoothly. This technique is even harder to get right when the processing in question is multithreaded, or if the spinner is part of the UI (as opposed to a cursor) so it has to trigger a redisplay to show up.

So programmers didn’t like it because it was complex, and designers didn’t like it because the animation was jerky.

As a result, the standard way now is to have an independent animation that you just turn on and off, which means you can’t tell if there’s actually any progress being made. Indeed, in modern MacOS, the wait cursor, aka beach ball, comes up if the program stops telling the system not to show it (that is, if it takes too long to process incoming system events). This is nice because it’s completely automatic, but as a result there’s no difference between showing that the program is busy doing something and that the program is permanently frozen.

Solve the halting problem to show accurate spinners

But if you expect the request to take some amount of time, how do you communicate that to the user?

Even if you don’t know the actual progress, the spinning cursor still provides useful information, namely “this is normal”.

Edit: Fwiw, I would agree with you if we were discussing progress bars as opposed to spinners. Fake progress bars suck.