Someone would need to champion this change. You describe it as only a bureaucratic process of approving standards, but supporting a new architecture across the python ecosystem is much more than that. The community of c-extension maintainers (NumPy, SciPy, pytorch, arrow, cryptography, pybind11 are just the first few of thousands that come to mind) must now decide whether to release wheels for that platform. If so how can they test them, since there is no CI that supports LoongArch and emulation is sloow. Conda must also decide whether to roll out support for the new architecture. This added burden is not something to be taken lightly, so it is only fair that there are some hoops to go through to get the support recognized.
I think you can follow the example of musl, which started with PEP 656, went via a few discussion threads and a PR to packaging.
You are correct that the macOS support for arm64 did not go through a PEP process. But there was a long discussion here and subsequent PRs to pypa/packaging. The adoption process for c-extension library maintainers was, and is still, quite an effort.
I could not find a similar discussion for the win-arm64 tag here. I think since the pypa/packaging/tags.py code uses sysconfig.get_platform() for windows, which needed no adaptation for arm64. However it too suffers from a lack of adoption, even the cgholke repo for such wheels is still “experimental”.