That would be helpful. One way you can achieve that is by introducing pictures. Everybody likes pictures and so far PEP 602 is clearly superior in that regard 
Joking aside, I doubt we’d see much adoption of the beta stream as described. For users to be able to tap into it, libraries would need to be consistently available for it. For a library maintainer making binary wheels available for those betas is laborious enough but first they’d need to make sure their library works at all. If this is already a concern for an annual release cadence, I can only imagine it being a deal breaker in an every-other-month cadence. This is my -1 right there.
But there’s another thing that bugs me here. One of my goals with PEP 602 was to help the core developer, the volunteer. Make things more predictable, easier, smaller. PEP 605 on the other hand leaves the current status quo intact (stable releases made rarely and thus large) while adding additional complications to core developers. The expectation would be to keep the master branch suitable for production use. Last month and the many adventures we went through during that time shows the team is not quite ready for that.
Finally, despite what the PEP here suggests, I still believe the annual release cadence would get features faster to users. Both compared to the status quo and to what PEP 605 is proposing. Sure, maybe not every user would be able to use the latest version every time. However, every new version of Python would see adoption of a significant subset of those users. After all, it’s not like all users would orchestrate skipping the same versions, right? On the other hand, I feel that the beta stream wouldn’t see significant adoption. So, new features would be guaranteed to reach almost all users slower.