Still, sad state of affairs that it seems like Apple is still fixing bugs based on what blog posts gets the most attention on the internet, but I guess once they started that approach, it's hard to stop and go back to figuring out priorities on their own.
I almost guarantee there is no way they can read this blogpost, escalate it internally, get the appropriate approval to the work item, actually work on the fix, get it through QA and get it live in production in 3 days. That would only happen on really critical issues, and this is definitely not critical enough for that.
I've seen a blog-post, authored a bug in Radar, assigned it to myself, and fixed it the same day. Whether it goes out in the next release is more a decision for the bug-review-board, but since the engineering manager (that would have been me) sits on that too, it's just a matter of timing and seeing if I can argue the case.
To be fair, the closer we are to a release, the less likely a change is to be accepted unless you can really sweet-talk the rest of the BRB, and there's usually a week of baking before the actual release goes out, but that has sometimes been shrunk for developer-preview releases...
The releases are the things that are few and far between - generally though, a nominated daily-build (based on the pre-determined release schedule) is triaged and tested by QA and engineering for a while before release, and then ... it's out there...
...Unless something goes unexpectedly wrong with the nomination, anyway. That's pretty rare because builds are constantly being made, regressions identified, and new bugs discovered and earmarked as "must-fix" (or whatever) on a daily basis. B&I have a fairly good feel for how things are going at any given time.
It's really just timing. If you can squeeze another fix in before the cutoff deadline for the nominated build, you're in. If not, you wait until the next one, which can be a while...