Is this a joke, swiftchocobo? There are so many issues with this implementation, even if you disregard the sloppy syntax and bad coding practices. As OP writes, "there are far too many AI for the server/headless clients to handle currently". For example's sake, let's assume 200, but that's on the very lower end, I reckon.

{
   [_x] spawn 
      {
      _unit = _this select 0;
       while {alive _unit} do {
          sleep 5;
          [_unit] spawn fncCheckRadius
      }
   }
} forEach (allUnits - playableUnits);

This thing right here spawns a loop for every single non-player unit, and that loop in turn spawns a function every five seconds. That's 200 loops with an additional 200 spawn commands every 5 seconds, provided the mission only has 200 AIs. And the function you spawn:

_nearEntities = _unit nearEntities ["Man", 1000];
_check = false;
{if (isPlayer _x) then {_check = true}} forEach _nearEntities;

uses nearEntities, which can be a rather demanding command. Say you have a platoon of 30 men, all withing the search diameter of each other. Every single AI will check if every single AI, bunny or snake within the search radius is a player. Even if we disregard the wildlife, that's a total of 870 redundant and utterly useless isPlayer checks pr platoon. OP wanted 2100m spawn radius, so you can imagine how horrible this will turn out to be. Finally...

if (_check) then {
[[_unit], "fncEnable", false, false] call BIS_fnc_MP;
} else {
[[_unit], "fncDisable", false, false] call BIS_fnc_MP;
};

broadcasting the functions that runs the enableSimulationGlobal and hideObjectGlobal commands to the server, once for every single AI on the map, regardless of whether these commands has their state changed or not. These commands should only be run on the server in the first place, there's no need to use the MP framework. There's no need for the last false in the argument list of the BIS_fnc_MP call either, since that's the default value.

If there is some reasoning to this that I've totally missed, feel free to point it out. Until then I will strongly discourage OP from implementing this solution. Code like this is how /r/arma ends up full of posts complaining about low FPS in multiplayer.

From the top of my head, how about checking the distance from each groups leader to the players, then switching the whole group on/off if a state change is needed, and run it in one loop on the server. That would surely be faster than this, probably by several orders of magnitude.