I think the reasoning was that there was a race condition between the code causing the bluescreen and the code updating to avoid the bluescreen so rebooting 15 times would give a lot of opportunities for the updater to win the race.
But if it was a race condition, then some computers would just boot normally. I didn’t see anyone report that the issue was happening selectively. And that wouldn’t even be fix, just a one-off boot. Unless the file is removed the issue will come back on next reboot.
It’s probably one central server controlling access to the network or distributing images or something. So they need to reboot one machine in that cluster enough times and all of the machines in the cluster will work.
The vulnerability broke every machine, the fix was the one that took multiple reboots to apply.
I’m not sure we are talking about the same issue. In case of CrowdStrike, the update pushed a botched file that crashed the kernel on boot. Until the file was removed, the machine wouldn’t even boot to be patched.
