That blog post was written a decade ago (!) and was mainly trying to make a different point about not fussing over pointless performance questions - there's more useful and more up-to-date advice in the manual section on Performance Tips.
The specific example with collision checks was probably made redundant by the subsequent collision cells optimisation, which is far faster, assuming the objects are all reasonably spread out. It completely avoids the N x N collision checks scenario.
However there are still other ways you can end up with, say, 10000 tasks that you want to perform every tick. It's true that if you can't do that in one frame, then doing it irregularly will jank. Here are some better ideas:
- Only do some of the tasks, rather than all (e.g. for content on screen or near the viewport, rather than across the whole layout)
- Lazy-compute things when actually needed - i.e. don't do any of the tasks, but if you detect that 100 of them need doing in response to some player input, perform those on demand
- Spread the tasks out by rotating through them, e.g. doing 1000 tasks per tick, meaning it takes 10 ticks to rotate through all 10000 tasks. (Note however this adds a subtle framerate dependence, so it may have to be designed carefully.)
- Redesign things so you don't need to do that in the first place (which depends on what exactly you're doing)
- If you're willing to write JS code, you could start a Web Worker and crunch through all the tasks in parallel to the game running without affecting the framerate at all. (The Pathfinding behavior adopts this approach internally so expensive pathfinding calculations don't affect the framerate, no matter how heavy the workload.) Not all types of tasks lend themselves to this approach though.
In general, be a little wary of advice from posts that are many years old! Things change a lot over time.