You said “automate those”.
What would the automation be?
I think I compared them once or twice some years ago.
Understanding how the mirrorlists and pacnews both work .. and having my own mirror ranking tool I wrote .. means I simply ignore them and rank my mirrors when I want.
Depending on the functions and quality of whatever tools you use to rank your mirror then you may similarly just want to remove the mirrorlist pacnews when they are created. Maybe remember to run your tool(s) as well.
But i cannot say that definitvely as the single solution because different systems are managed differently - some ranking tools source what they would rank from the mirrorlist files so need the standard one. Others pull from online resources. These kinds of differences are also among other reasons why pacnews are the way they are - the whole point is that a file did not perfectly match upstream, which indicates custom changes, so a pacnew is created instead to respect those custom configs and users must inspect them to make their own decisions about what to do with them. This is intentional design.
The way to end the ‘package providing standard mirrorlists is updated while many users do not need or want the standard mirrorlist files’.. to my mind might be to reorganize how things work. Have the packages provide non-live files and the tools write live files. That is the package would give you the default mirrorlists somewhere like /usr/share/pacman/mirrorlist, etc and pacman will read from an active shaped mirrorlist at the normal /etc/pacman.d/mirrorlist path (tools will write to here). I suppose it is not really seen as necessary.