Assuming no bugs, we thought it was ready. But there were bugs, so it was not and we fixed them. Also, we will sometimes do an rc even with minor known issues to be addressed in the next rc to give people a chance to get the rest of the fixes they may be waiting on. This is all standard software development practice. It’s also a signal for the kind of changes that may go into the release. E.g. at this point we’re no longer gonna add any deprecations (with the usual disclaimers that common sense supersedes policy). Additionally, rc1 has traditionally served as the branch point where master re-opens for (breaking) changes for the following release, with bugfixes being backported manually. Because CI wasn’t ready to handle the 1.0.0 version, we delayed the branch point this time to save some work. Also, 1.0 is special in that it doesn’t have any additional breaking changes (though we will start merging deprecation removals very soon to master).
Really, the point of doing all of these pre-releases is to signal milestones in development, and get people to seriously test their packages. Whether there’s an exact policy that specifies what does or does not count as an rc is mostly irrelevant to that purpose. From the user’s perspective, alpha => may want to start testing my package to see what broke, beta => good time to upgrade if you have the time, rc => better upgrade or your package may be broken on the release.