To refocus the discussion a bit, I think this is the problem statement:
Others have pointed out other reasons for wanting a more regularly released “unstable Rust,” but as far as I can see, most of them resolve to some variation of “nightly Rust is too inconvenient to use.” I think that’s exactly how it was intended to be. De facto stabilization is a real thing, and the more convenient we make unstable features to use, the more at risk we are for de facto stabilization. If you need to use nightly for feature X but feature X is unstable and nightly is too inconvenient, then, we should try to make feature X usable on stable (even if that means that it takes months, or perhaps in some cases, years). The inconvenience of nightly Rust has utility: it is a good forcing function to stabilize stuff that a lot of people want.
The problem stated by @nrc is directly at odds with that line of thinking though. 
I agree that it’s a real problem. There are many instances where we just really need people to gain experience with a new unstable feature, e.g., the new std::panic module. If we continue to make unstable features inconvenient to use, then we aren’t going to be able to collect the data we’d like, and we risk stabilizing something that has flaws that would have been uncovered with more practice.
I don’t know where I land on this personally. However, I do think it’s valuable to keep the key trade off in mind: risk de facto stabilization or make it harder to collect data on experience with unstable features. If we can come to a consensus on that trade off (which certainly isn’t binary), then it might be easier to figure out the implementation details (like an “unstable release”).
