If you NEED say, 10k edits... it's gonna take days for that script to run. Might as well just wave bye-bye to any use of the homepage for that period. For a few dozen to a few hundred edits - stuff that isn't worth finding someone to use the built-in tools for - script away and deal with the fallout (which is to say, communicate what you're planning well ahead of time)
Realistically, avoiding rate limits is trivial - just pick a sensible delay and, upon hitting a rate limit, back off for a minute or so. All of this can be done very efficiently with scripts except for the bit @Catija mentions: avoiding absolutely trashing the front page on quiet sites.
@VLAZ I have such a script around somewhere - it loads the tags on each post first before applying changes, so as to avoid the need to pre-load all affected questions. But another sensible approach, and one I've used for very large and complicated operations, is to use SQL to generate rewrite requests based on post data - the downside of doing this as a normal user is the lack of access to current (up to the minute) data; using SEDE for this is likely to corrupt some posts.
Crucially: it does not act as an arbiter for close or reopen votes. It cannot, not without a massive change to how it works today. If you look at my example and imagine that a negating review was given the opportunity to nullify votes... Then some guy named "Rob" would have nullified more votes than he could have actually cast on the question under review. It is a heavily biased system, saved only by the fact that its power is derived almost entirely from presumed apathy...
It is... Like training wheels, or some other sort of assistive device: it tries to provide a structure and coordination for what was already possible without it, in a way that scales a bit better than, say, a group of folks in a chat room.
The review system is, strictly-speaking, optional for close and reopen: questions can be closed, not-closed, reopened and not-reopened, without anyone involved touching review.
Over just the past year, that question has been in reopen review 7 times. During those reviews, some of the same reviewers have reviewed the same way multiple times.
IIRC it was Geoff who made the argument that we call them votes and thus the mechanics should reflect that: nobody should be able to just make them go "poof" for arbitrary, capricious or unknown reasons.
@Catija because review wasn't intended to change close mechanics, and there is no "clear" for votes (that's not 100% true now, but it was in 2012 when this was designed)
But... Things being what they are, it is a balance between giving 3-5 people some autonomy in high-traffic areas, and giving 1-2 people assistance in low-traffic ones.
My personal opinion is that voting to close is more trouble than it is worth: if closing was as easy as editing and as easy to correct as a bad edit, this would all be unnecessary.
Well, I hate the whole, "everyone left and I'm tired and there are dirty glasses everywhere" thing. But the biggest motivation is just... I don't like sitting still. Gotta be something to do; walking, working.
Short summary for short attention-spans:
Read answers below, vote them up or down based on how they align with your own perspective.
Write your own answer to the question, What change has the company made to Stack Exchange made in the past year that will have the greatest long-term impact?
Summ...
FWIW as a ... Much less-recently separated employee... I'd cosign @AMtwo's observations here. Everyone knows the term "bus factor" - you don't put a responsibility on a single person unless it doesn't matter much; critical stuff gets redundancy. That there's no redundancy here speaks volumes about how little SO as an organization cares about all of these concerns.