I'm absolutely right

As I opened the website, the “16” changed to “17”. This looked interesting, as if the data were being updated live just as I loaded the page. Alas, a refresh (and quick check in the Developer Tools) reveals it’s fake and always does the transition. It’s a cool effect, but feels like a dirty trick.

Reminds me that the reason that loading spinners spin is so that you knew that the loading/system hadn't frozen. That was too hard (you actually had to program something that could understand that it had frozen), so it was just replaced everywhere with an animation that doesn't tell you anything and will spin until the sun burns out. Progress!

…although in many cases you kind of don’t have a choice here, right? If you’re waiting for some API to return data, there’s basically no way to know whether it has stalled. Presumably there will be a timeout, but if the timeout is broken for some reason, the spinner will just spin.

You can't figure out how to fix that? Does that problem seem impossible to you?

Maybe don't start an animation, and instead advance a spinner when a thing happens, and when an API doesn't come back, the thing doesn't get advanced?

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.

You have a strange idea of what "right" means.

Showing a true reflection of the actual, irregular, progress is getting it right. It's honest and informative.