If you’re biased this way then so am I
My thinking on the two stream model is almost too biased towards the library developers and against the application developers.
To answer in terms of the concrete answer you asked:
>=3.10 OR >=2020.08 is an unnecessary condition, because the latter is implied by the former But the idea is that your package “probably works on latest” and “works on >=3.???”.
The trick is that users must be on the latest fast track release. That’s an explicit requirement. It’s not enforced, of course, until someone comes and says “why doesn’t package X work on latest from two months ago” and you say “latest != two months ago; update and come back”. The CalVer is less about versioning and more about making it easy to see when a user is in the wrong place - they’ll show up with the version number, and you’ll know straight away either that you have a new/current problem, or that it’s irrelevant.
And once you know you have a problem, you fix it in a way that works on the latest stable 3.x version, as well as the latest release from the fast stream, and then you’re done. You don’t have e.g. 3.8, 3.9, 3.10 and 3.11 beta all active at once, just two versions. Which means the app developers are more likely to have to install dependencies from source than before, but the library developers don’t have to maintain as many Python versions.