This change provides the following advantages:

While the ease of switching to calendar versioning can be treated as an advantage of an annual release cycle, this PEP does not advocate for or against a change in how Python is versioned. Should the annual release cycle be adopted, the versioning question will be dealt with in a separate PEP.

Adopting an annual release calendar allows for natural switching to calendar versioning, for example by calling Python 3.9 "Python 3.20" since it's released in October '20 and so on ("Python 3.23" would be the one released in October '23).

This change does not shorten the currently documented support calendar for a Python release, both in terms of bugfix releases and security fixes.

This change does not accelerate the velocity of development. Python is not going to become incompatible faster or accrue new features faster. It's just that features are going to be released more gradually as they are developed.

Consequently, while this change introduces the ability for users to upgrade much faster, it does not require them to do so. Say, if they upgrade every second release, their experience with Python is going to be similar to the current situation.