No double standards please. Allowing (1), (2), (6), (7), and (10) but not this seems silly.
A reclaim brush can be implemented in a way that limits processing cost per unit time (just think of your own fabber behavior XP), and thereby avoids stutters.
Also, based on the numbers you listed, I think you're imagining a larger brush size than I am, and a smaller brush size would result in faster processing the way I'm imagining implementing this. Regardless, the brush size (or max brush size, if adjustable) could be tested in FAF develop and set to a sensible value.
Regarding the command queue; if it would be necessary, adding an arbitrary limit to the maximum number of units that the reclaim brush can issue to a unit would not be the end of the world. The user already has to deal with numerous arbitrary limitations to the game (ie: max number of concurrent message markers, attack move's odd arbitrary functionalities, templates' inability to properly handle t1 pd-sized objects at full density in combination with larger objects, the arbitrary values used by your new automated fabber behavior, an apparent arbitrary inability for many units to target priority ACU, an arbitrary unit cap, an arbitrary input lag, etc).