An actual Package Manager _is_ the installer - they are part of the OS and know how to correctly install and fully uninstall things. Someone else in this thread wrote a nice summary of this aspect here: https://jmmv.dev/2022/03/a-year-on-windows-winget.html#unins... This part is mostly true with MSI's, they're just a package format like .deb or .rpm - they just don't have any of the other infrastructure around them.
> It does in fact centralize the update flow, but that's only beneficial when you update everything at once, which I don't have any reason to be doing: either I want it on latest, with the only interruption being not quite yet, or I don't want it updating at all
Having this all centralized is actually really nice, so I wouldn't discount that. If you want to pin a package at a particular version, you can and the package manager will leave it alone. If you don't want things updated yet, just don't run the update yet.
With a package manager I have to trust one organisation, which is the same that I get my operating system from. I don't even have to trust the website that hosts the packages, since the packages are signed. It's true that someone might try to sneak malware under the package mantainer's nose with obfuscated source code, but that's much harder than sneaking it in a binary. You're practically guaranteed that the software running on your PC matches the publicly available source code, and it's built with the latest compilers and hardening flags. (7-Zip used to build without any hardening flags because they made the binary larger.[1])
It's not even just security issues I'm concerned about when it comes to trusting software. I also have to trust the software not to make global, permanent changes to my system, which isn't uncommon with Windows software[2], but basically unheard of with Linux packages - and when it does happen, it's Microsoft doing it[3]. So I'd say the primary meaningful value-add of a package manager is trust.
[1]: https://landave.io/2018/01/7-zip-multiple-memory-corruptions... [2]: https://devblogs.microsoft.com/oldnewthing/20081211-00/?p=19... [3]: https://www.preining.info/blog/2018/06/microsofts-failed-att...
For fetching development libraries, it's huge.
If I run `make` and it turns out I need libfrobnicate-dev, I can just quickly `sudo apt install libfrobnicate-dev`. I don't need to pull up a browser, Google it, find the MSI, make sure I'm grabbing the right version (Seriously why the hell does 32-bit Windows still exist?), download, and run it.
Oh, and what about when that dev library gets a new version? `sudo apt upgrade`. Done. All my libraries get updated, no need to track down 20 MSIs.
If nothing else, unlike downloading and executing a MSI, apt will download the package, verify its checksum, and verify the signature of the package itself.
In my, albeit limited, experience of showing someone how to get something on linux, the reaction usually is : "what? ....why? is it installed now?", shortly followed by : "Is there like an app i can use to install what i need instead?"