I dunno... You really need to fix something like this quickly and you might not have time for a really good QA round; so you rush it. Could they do better, sure.
You really need to ship an operating system that doesn't get into a crash reboot cycle at the turn of a new month.
Meanwhile, just this year we had these bugs here and before that we had the "password got stored in hint field" one with new FS[0], some other one with keychain stealing[0], the Unicode problem with the new FS, the iPhone calculator bug with intentionally laggy animated + button ignoring input.
I'd expect them to walk on (colibre) egg shells for a few weeks now, some of these bugs are absolutely embarrassing (compared to bugs like Debian's OpenSSL RNG bug for example, which is a more nuanced one that requires real analysis and thought to find and understand properly as opposed to "my password is just shown" that anyone can understand).
I'm pretty negative towards Apple for reasons but if someone told me a year ago they'd have so many bugs in such a short time period I'd say they're being disingenuous since Apple has many real downsides (that it's users mind not care about but I happen to) but top quality.
[0] - http://mashable.com/2017/10/06/high-sierra-password-fix-appl...
Here's how I'd model it. The main decision point on Apple's part is how long to QA the fix before pushing the release out. As soon as the build finishes? 3 hours of testing? 1 day? 3 days? 2 weeks? The longer you test, the lower the probability of introducing a regression or having an incomplete fix, but that probability never drops to zero.
You could come up with an "expected after-patch defect severity over time" graph that goes down (due to more QA) in a way similar to exponential decay, and compare with that with the known before-patch severity of the root access bug (which was extremely bad in this case, obviously). A simple way to make the "how long to test" decision is to say that if the expected after-patch severity is lower than the known before-patch severity, then you should release. (That doesn't mean you need to stop testing, obviously.) A more nuanced decision-making process would take into account the confidence level from the QA process, the overhead of the release process, and the bad PR of releasing a buggy fix. But still, if the software has a terrible flaw and you have a fix that you're reasonably confident won't make things worse, it probably makes sense to release it.
Apple ended up taking about a day to release a fix. My understanding is they also released it as a user-initiated update for a while, then later forced the update on everyone, which seems like a fine strategy to reduce risk of widespread regressions.
Inventing a rating system, I'd say the severity of the root bug was 100 and the severity of the file sharing bug was 10, so the patch they released was an improvement even to users who ran into the file sharing bug. So over the course of multiple patches, their computers got better, even if was from terrible to bad to normal. I also think it's not obvious that another day of testing would have caught the file sharing bug, and taking 2 days to release a critical security fix is much worse than taking 1 day, in my opinion. So my impression is Apple generally made the right choices about how to release the patch, even if it's crappy that there was a regression and that such a bad security bug would exist in the first place.