Some people use the above for their projects themselves, for similar reasons, but I just use the now-ubiquitous env and version-manager programs for that (nvm, rvm, that kind of thing). Again: documentation, consistency, and isolation. Even if your dev set-up isn't used for deployment, if it's scripted then it's also accurately documented. As for language-specific libraries and tools, even if a few are in some package manager, I wouldn't rely on them. The language's own package manager will work everywhere, will probably be more (maybe much more) up-to-date, and you're going to need it for some stuff, inevitably, so you may as well use it for everything the project needs from that language.
[EDIT] notably, this way of working means none of my/our projects give a shit what OS or package manager anyone is using. Prefer macports to homebrew? Running Void Linux? Slackware? Probably even Windows (I dunno, who cares, it's Windows, but probably it works)? Go nuts with that, live your best life or whatever, the projects don't care. You'll likely need to manually create a Linux VM for Docker if you're on a BSD, but if you're on a BSD that will be the least inconvenience you face this week. I truly don't get why anyone would just "brew install postgresql" or "apt install postgresql" and use whatever happens to come down as an implicit project dependency in this, the year 2021. Because you actually want to directly use a local database to do database things? Sure. For a project that will be distributed or deployed elsewhere? No no no no no. Not even if you're running the same OS as your servers. Or Ruby, or Node, or even your compilers if you can help it. You have to be more specific and keep your shit tidier than that if you don't want a bunch of pain, both now and later, and almost all of that's very easy to do now.
Arch does seem to be about as good as Gentoo's portage, which is the best selection I've yet to see in a Linux package manager. I'm not interested in a rolling-release base system anymore, though, because I just don't have the time or patience for "running update broke X/Wayland/audio/wifi/boot" these days, or fiddling with whatever it takes to keep that from happening. Rolling release applications? That I like.
Arch does much better, but a quick search of ones I guessed might be missing turned up the following missing, from what I have installed on my Mac:
- rolldice
- android studio (package name android-studio in homebrew)
- tealdeer
- heroku (these are the Heroku command line tools)
- sublime text (package name: sublime)
- postman
- slack
Maybe you can add other repos to get them on there, but I usually just guess the package name and get what I want. I don't think I have a single thing on my Mac, as far as software I directly use (not project dependencies), that I didn't install with Homebrew, aside from first-party Apple software (Pages, Numbers, Safari, Xcode, Mail, and so on). And that's not bringing up all the Mac-only software I've installed with it, which obviously wouldn't be fair.
I haven't added a single extra repo. That's just with the defaults. You used to have to do a one-time invocation to enable binary-only packages (mostly closed-source stuff) and then use a different keyword for operating with them, but that's no longer the case and hasn't been for IIRC at least a year—it's all transparent. "brew install [guess at package name]" works almost every time I need it, and a "brew search" finds the rare failures. I basically never need to open a browser to find & download software, and it's all up-to-date, and it's all totally separate from my base system so is extremely unlikely to ruin my morning because I ran a blanket update-everything-to-latest and didn't pay enough attention.
PS: Debian has > 3x as many packages as Arch[1]. It would surprise me very much if that was just a matter of things being more split up in Debian, or Debian's higher count of virtual packages. When people talk about Arch's great selection of packages, they're including the AUR, which is actually massive. Imo it makes more sense, then, to include the AUR in little tests like this.
—
In particular, I've not seen a package selection so good and so consistently up-to-date, with so very little fiddling or upkeep to add or maintain 3rd-party repos, since I was on Gentoo—and portage broke (in whole, or just had broken individual packages) a lot more than homebrew does (which is almost never). I can't think of a single thing I use that isn't available and well-maintained on it, open or closed source. Even obscure things often just install on my first guess at the package name, no muss, no fuss.
Now, what I don't use it to do is to manage project dependencies, but then I don't like using, say, the "system" PostgreSQL or Nodejs or whatever even on Debian, either, unless I'm using them directly and not making them part of a project that will need to be distributed or deployed elsewhere and worked on by others. I'm entirely fine keeping core OS parts, my personal software I use, and management of individual project dependencies, strictly separate—in fact, having worked this way, I prefer it.
I could be tempted away by a similarly-great and high-quality package selection, maybe, but that would be table-stakes before we even get into the rest of how the package manager operates.