The "problem" is that 3p developers don't want to get with the program, and insist that the only possible way to install their magic sauce is to spam files all over the system. And that therefore there must be a super-complicated set of add-on tooling to deal with tracking all these files and their dependencies.
It's job security, of a sort, I guess.
- That's only for GUI applications. Almost everyone reasonable developing GUI apps for macOS uses this method. However, CLI apps also have to update $PATH, which involves running a script. Package managers handle doing this better than macOS's frameworks because they were designed to do such a thing.
- There's absolutely no system for updates. Each app has a separate daemon consuming background resources just to check whether it has an update available for itself, and every app has a different way of actually installing the update. Just try having a system with Audacity, Adobe, Chrome, and Microsoft Office installed and you'll see what I mean (Microsoft Office and Adobe have a separate app installed just to update their original apps, Chrome installs updates in the background by sneakily updating its .app file, and Audacity just tells you an update is available and makes you restart the app to install it). This is why Homebrew manages .app files despite the fact that a “package manager” already exists for these*.
[note] I'm ignoring the App Store because most macOS developers don't submit their apps for the App Store because it's restrictive in many ways
- Using a package manager allows saving storage space and RAM usage for dependencies – only one copy of a library is loaded into memory and stored on disk
This is why apps to manage packages (e.g. Homebrew) exist. While we can debate the merits of Homebrew itself in terms of how well it does that, Homebrew does, in fact, solve a problem. If you believe it's not necessary to solve this problem, you can install the apps yourself, of course.