That's the fighting example. Fights generally develop a rhythm, where people trade punches. You can get a big advantage by striking when it's not "your turn", even if this means waiting.
Having said that, AlphaGo and the deep learning starcraft bots look like they are starting to approach that kind of exploitation of the adversay's OODA.
I do like you bringing up starcraft though. Clicks per second can largely be mapped to the frequency of the OODA loop. When I was following the broodwarAI bots a couple of years ago, usually the better bots tended to have a much higher meaningful clicks per second than worse bots. This of course, isn't necessarily causative, since the better algorithm may spend more time on analysis so that it clicks less, but each click is more valuable.
But I think you are right, in that the bigger idea OODA was that the reason the pilot who came up with the idea originally was using it to describe why his largely inferior plane was able out dogfight enemy planes. That the plane he was in had more responsive controls, which allowed him to react faster to his opponent, and also to keep forcing his opponent to get stuck reacting to his actions. His basic tenet was that because his plane was more responsive, he was able to keep forcing his opponent to have to go back the start of the opponent's OODA loop every time he changed course, thus wasting precious time observing and reorienting.
Col. Boyd wasn't just talking about fighter pilots. Much of what he was talking about have a lot of relevance to fighting in general. I find a lot of skilled martial artists breaking someone's tempo. Musashi and Sun Tzu have talked about it in each in their own way.
Put it this way. I have a friend who regularly beats people on first person shooters. He does not have fast reflexes. He just knows how people think and react and can manipulate them.
But I don't really care. It isn't as if I were going to go out fighting someone seriously anytime soon. And if I were, I wouldn't want to teach my adversary how to use OODA properly.
I spent a good amount of time writing situated agents in persistent worlds (aka bots for things like everquest). My experience was that the tighter the feedback loop the less the bots would get stuck in weird places. So when I first was exposed to the concept of OODA, it was very clear to me that the concept mapped very neatly to the work I'd done. All the bots I've written got better essentially the more frequently I applied the OODA loop.
You'll also find if you read the literature on situated agents, that robots got much better much faster once scientists started building them to react to the world, as opposed to the early days where it was assumed they'd need to build these massive models of the world for the robots who would then need to spend massive amounts of CPU time trying to decide what to do next.
What I think the article may be missing, when it talks about half-beats, is that ideally you really want to iterate over your OODA loop as fast as possible, so that you can make more decisions than your opponent. The first step is often to define your Action in the smallest timestep that you can. So if your opponent thinks one step is their smallest action. You should really be trying to define the smallest action as a half step. Now you can potentially make 2 decisions in the same amount of time. Then do this for each stage of the OODA loop. Find a way to Observe faster. Find a way to Orient faster. Find a way to Decide faster (even deciding to defer deciding until the next OODA loop).
At the end of the day, your sample rate and your real time deadlines dictate a lot about how an agent can act. And don't get me wrong, a good algorithm will always trump a high sample rate, but don't underestimate just how important a high sample rate is when talking about an OODA loop.