"RC" is not an excuse to flush semver down the toilet. If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
That's true. Then again, an RC in semver is a prerelease version and "A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version." (SemVer 2.0.0, para. 9)
Breaking changes from an RC isn't flushing semver down the toilet, its fairly explicitly permitted in the semver spec.
> If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
No, if anywhere before the 2.0 release, including in any prerelease version in the 2.0 line (even an RC) you discover the need for a breaking change, that's fine per SemVer, and the major release that comes out of resolving those issues will still be 2.0.
If you have a bunch of active, unmerged, and API-breaking branches where you're not sure which one is going to make it into the release, don't call it a release candidate because you're planning to change the API. (I don't know whether this was the case with Angular, I just assume it after reading the rant.)
If you are planning on changing anything it shouldn't be a release candidate.
OTOH, the reason for the "candidate" part of "release candidate" is that things may still change from the plan.