This scheme is based on PEP 600, which from my understanding is the preferred approach going forward. It’s definitely possible to use the year-based approach if you are willing to take the responsibility to update the year number periodically for the community. I’m not doing that.
I see little benefit in using a year-based scheme in practice either (for musl specifically). The most popular musl-based distribution by far is Alpine, the base image of which only contains one additional library (libz), so a year-based scheme is little more than a mapping that translates musl version to year number.
Year-based manylinux platforms limit architectures to i686 and x86_64 because that’s what CentOS has. A libc-version-based scheme does not have the same constraint, and applies to any architecture that runs musl and Python.