It reminds me of my boss emailing gnu.org to tell them one of their mirrors was down and got a nastygram back that said "It's spelled GNU/Linux" and the mirror went unfixed.
They don't maintain the mirrors themselves. These are maintained by third party who decide to hosts the mirrors so there is that.
Also, Homebrew attempting to nuke /usr/local on uninstall left a quite bad taste in my mouth. I had installed MacTeX before Homebrew, and thankfully MacTeX had proper file permissions set up, so my TeX installation was left in-tact. Still scary knowing that this is just done in the background without warning (unless the operation fails with errors).
I'm sure someone will start a macOS package manager based on python and yum to signal the waning days of those technologies.
But it is unmaintained (it seems its author has moved on to Nix).
Its being in ruby is a strike against it, for me. I use it anyway. It’s probably my favorite package manager, all things considered, and I’ve used a lot.
As for why Homebrew packages seemed to be broken less often, I can only speculate. At least one big benefit it had was being on GitHub. A lot of folks were already familiar with how to cut a PR. Not so with how to submit a Portfile patch to the MacPorts Trac.
But Homebrew's fundamental tradeoff w/r/t purity was also a huge boost to installation speed at a time when most package managers for macOS still required you to build most things from source.
That and the slick, user-friendly UI were probably the biggest factors for Homebrew's success when it came out.
If I could switch entirely to MacPorts, I would.
It would be an interesting discussion to have, as they do have some of that sort of thing (the 1Password CLI, for example), but I don’t know what the general policy would be.
I’d love to see MacPorts get more funding for build resources and to potentially add that, because the way that Homebrew works occasionally leaves things broken (`pipx` venvs are a great example).
…Like I said, language X developers want all their tools to be written in language X, and their package systems too.