As best I can tell, that's partially due to the size of the community, but also because Homebrew went out of their way to teach the system to fish via the 3(?) different kinds of "check for updates" built into the Formulae:
When Homebrew started (and when I switched) the community was significantly smaller than MacPorts. It is due to the system you mention (and the community that this MX in turn cultivated) that allowed brew to dominate the mac packaging market.
Absolutely MacPorts and Sapphire can adopt the same strategy, but the point is that brew already has, so what exactly would the benefit be? e.g. if the language of choice is effectively meaningless, re-writing homebrew in Rust serves effectively no purpose. This is contrasted with systems and software where the performance or correctness is the most important feature, and therefore RIIR can be a big win.
Said another way: Brew was not "re-write MacPorts in Ruby", it had much loftier goals which it then executed on effectively. Sapphire mostly seems to be "re-write Brew in Rust", without much beyond that. So the only real gain is a bit more performance out of the CLI.
- GitHub release sniffing https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f...
- page scraping https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f... (and also per-content-type flavors json and presumably xml)
- links to other formulae (IOW cascading updates): https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f...
and then the $(brew livecheck) invocation which will do a subset, a curated list, or hypothetically all of them
I can't imagine why MacPorts or our new Sapphire friend couldn't adopt a similar strategy