This is the solution I'm running with:

First, I made sure that the running average for total tick usage is calculated before calculating map_countdown. Previously it was calculated after ward, allowing for it and the nonmap usage to get out of sync by one tick. Not a huge deal but worth fixing.

Now when world.cpu shoots above 120, it calculates how much of the running tick usage is map-related as a simple fraction (f). The number of map ticks to skip (s) is calculated by f/(1-f), so that it's equivalent to saying f ticks of map plus 1 tick of everything else has the same usage ratio. The maximum value of s is world.fps-1, and s is rounded off to the nearest integer.

The upside of this is that not only does total usage have to shoot above 120, but the map's portion has to be at least 33% for this to matter at all. At f=1/3, s=0.5 and would round off to 1. It'd have to reach 60% before it started skipping 2 map ticks.

In practice, it should be extremely rare for a game to experience conditions where the map uses up such a huge chunk of server tick time, as usually the bulk of computation burden is from running procs.