The Myth of Perfect Package Management
Linux distributions are often praised for their easy to use package managers and repositories. And I get that, the promise they make is amazing. But the reality is often disappointing.
Often the piece of software you want to use, and even a quite popular one, isn't available in the officially maintained repositories and you end up following official tutorials (that may not work) or even running installer scripts (that also can fail quite spectacularly). And if the package is available, it may be a severely outdated version—though hopefully still supported. In such cases, you might end up resorting to alternative sources anyway.
And let's not forget about dependencies marking. I get it, when you install a distribution it gives you a lot of tools and gadgets. When you install a desktop environment using a metapackage it pulls a lot of packages. That makes perfect sense. But I will never understand two things: why trying to uninstall a soundspack or app I'll never use fails with warning akin to "this will nuke your whole DE, don't do that" and why I can even see separate packages if that meta one is a giant, inseparable blob? It should've been made in a way the meta package contains a list of packages to install, but removing a tiny piece like a pack of sounds or cursors should never remove everything else from that metapackage!
And there are also container-like approaches in the form of Snap, Flatpak and AppImage. However, these approaches come with their own pitfalls. Either the isolation is too strict and app loses ability to interact with others, limiting certain functions. Or it is hard to register as a default handler for things and add to menus. Or it fails to run without apparent reason.
Besides that you occasionally encounter just a plain old archive to extract and run the binary, hoping all the dependencies are available. Or even a build instruction. This often leads to the deeper rabbit hole of developer dependencies, which can be even more frustrating.