There's a lot of "not finished so wasn't included in this release" in the release notes.
With, say, a 12 week cycle instead of 6 weeks, I'm waiting 3 months for My feature to land in the next release, and I feel a lot more pressure to get it done now than I would with a 6-week cycle where missing a release isn't a big deal.
Assuming the team has the release process we'll automated and cutting a release doesn't add a lot of work, then there's not much to lose with this cycle.
"should" is a nice ideal, but people will feel pressure, especially for tooling like a compiler that other teams depend on, where slipping schedule means slipping their schedule too. Shipping more often lessens this, by meaning a missed release costs much less time.
Empirically, Rust has done a pretty good job of shipping fast and not releasing regressions, so it seems like this isn't mutually exclusive.
I think that those few people who rely on the newest-possible features in the compiler will be compiling with a nightly build anyway (possibly pinning to a known-good version until the next release).
That's actually somewhat a meme within Rust, at least as far as my impression from the outside goes. There apparently were times where most interesting crates required some unfinished feature and thus a fairly recent nightly build of the compiler and/or Cargo. I believe that problem has decreased in the meantime, but as I said, I'm looking into Rust from the outside only and don't have much own experience.
According to the developer survey last year, most of the community is using a stable compiler in some form[0]. I can only imagine that the ratio has improved since then, especially with custom derives in 1.15. Additionally, I semiregularly see people say that they don't use nightly in production, even if they're using it for preview/experiments/testing.
Well, unless you made a huge regression that's killing your users... which ironically is a recurring issue alleviated by releasing slower and testing better, not by releasing faster :D
Actually, releasing faster might help avoid regressions since a faster release cycle requires you to focus more on continuous testing practices. With, say, one release every 2 years, you can easily put off testing until a few weeks before the release, at which point regressions are found and panic ensues. If you release every few weeks, you need to be testing all the time to find regressions in time, so you will be forced to automate it.
With, say, a 12 week cycle instead of 6 weeks, I'm waiting 3 months for My feature to land in the next release, and I feel a lot more pressure to get it done now than I would with a 6-week cycle where missing a release isn't a big deal.
Assuming the team has the release process we'll automated and cutting a release doesn't add a lot of work, then there's not much to lose with this cycle.