FWIW, conda-forge still compiles against a CentOS 7 baseline, which corresponds to manylinux2014 == manylinux_2_17, which is also still in widespread use on the PyPI side:
In the case of manylinux, this is only for packages building on top of python (and with the exception of conda-forge, I don’t know how the python versions that people tend to install are built), so not directly impacted by how cpython handles this.
I’m the first to admit that download numbers have obvious issues (skew due to cloud providers, CI, caching), but still quite a significant amount of projects do not want to (or at least haven’t needed to) move to the manylinux_2_28 generation based on Alma8 yet.
Note that I’m generally advocating for keeping infrastructure baselines at least somewhat current, because I think that at some point the extreme end of the long tail of support does not balance out the effort necessary to support it. Still, it’s not exactly a popular task because people tend to think you’re taking something away from them.
So I provide this just as a datapoint, not as and “you need to support ancient Linux” admonition. If the reasons for moving on are strong enough, the case for moving the baseline can and should be made. But all other things being equal, if you can keep a working fallback that would also be cool 
FWIW, conda-forge only moved to 2.17 as a baseline a year ago (long story), and I don’t expect a move to 2.28 soon. That is, unless core packages like python start requiring 2.28, which would certainly provide a strong argument to reconsider this.
PS. This falls into a similar territory as the discussion for macOS, where there’s also no explicit lower bound mentioned in PEP 11, much less a policy how that lower bound would move up over time.