It's an easy solution for lazy developers. maintaining dependencies is a hassle, and with proprietary software users can't even do it themselfes if the developers decide that an 8 year old ssl lib is perfectly fine. The distributions probably won't keep that lib around either, so the easiest solution for proprietary vendors who don't care about dependency updates is to ship it all in a self contained bundle.
It also makes it easier to clean up when uninstalling and makes for better damage control by limiting what can be broken if done right, but like the article said this is not what it's actually all about since noone seems to care about these points.
> It also makes it easier to clean up when uninstalling
I think pretty much every package manager tracks what was installed manually and what was installed as a dependency of something else, so that it's easier to just remove everything that is no longer needed.
With a traditional binary package manager for Linux, if some application needs a special version of a dependency, you need to install that special version of the dependency systemwide, overriding whatever would come from your default repos.
When you remove that package, you now also have to change the configuration of your repos to remove the one that it came from, or arrange a vendor change (the best case, with a powerful package manager like zypper), then run an upgrade to get the default one back into place.
What the GP is talking about is how containerized packages eliminate that step during uninstallation.
The solution is for the distro to provide multiple major and minor versions of a package. This is quite common.
If a program depends on a specific version of a library that's not provided by the distro (because it's obsolete, vulnerable, too specific etc), it still can be installed by the package manager, if the vendor provides a suitable version within the package. The nice way of doing this is to avoid colliding with the system-provided package either by using a different name or by installing it under a different path. Many vendors do precisely this when offering their packages.
In both cases, it's easy to uninstall the no-longer used dependency - on the first case, it'll be marked as automatically installed and can be removed with a cleanup command. On the second case, uninstalling the package should also remove the library.
All of the solutions you describe require special attention from distro maintainers, packagers, or users. In the case of Flatpak, it doesn't really take any extra work in terms of adding extra package definitions or creating new prefixes that coincide— the people packaging the Flatpak (usually the app developers, we expect?) can just modify whatever distro package is used to provide that dependency in-place and ship it out in their Flatpak as if there were no collision problem at all. Similarly, on the user's side, the collision problem you outline is preempted; Flatpak packagers simply can't prepare their dependency chains in a way that will actually conflict with libraries present on end users' systems.
There are some more traditional (in the sense that libraries are always shared by default and no containerization is required for packages to work right) package managers that extend the kind of isolation you describe (‘installing [special or patched versions of dependencies] under a different path’) to all packages, namely Nix and Guix. These package managers also make it easy to do things like take a package definition from somewhere else and rebuild it with just one or two dependencies modified without redefining the whole package, or alternatively take such a package definition (perhaps originally targeted to a different release version of your distro) and rebuild it with all dependencies instead being provided from your current distro. At the same time, since the dependency chains of packages are isolated by default in these systems, it's relatively easy, in case of a special need, to take any package and bundle it and its dependencies into a container for distribution on ‘foreign’ systems. (And for packager convenience, the package collections in these distros may also explicitly include multiple versions of a library in their default package sets in the same way that other distros do, as you describe).
Nix and Guix have their own difficulties and quirks, of course! But one of the things I like about their approach is that their innovation is conservative in a certain sense: it offers more isolation for packages (along with the cross-distro compatibility and potential for bundling that come with that) but preserves the virtues that have been the strength of package management on Linux forever. I would like for whatever really is the future of package management on Linux to share in that.
So I don't think containers are The Way Forward™, although I do think that desktop containers like Flatpak are potentially useful as (1) a step toward more fine-grained permissions for desktop apps in terms of access to files, multimedia devices, and so on; and (2) a way of providing cross-distro packages for applications that (a) have yet to accrue much developer interest from packagers and distro maintainers or (b) are (unfortunately) proprietary.
(Personally, if I really want a piece of software, it's not in the distro I'm currently using, and it doesn't seem especially difficult to package, I will just go ahead and make a package for the distro I'm using. Case (2a) provides a convenient, more managed way for me to evaluate a new program I've heard about without having to package it just to see if I like it.)
It also makes it easier to clean up when uninstalling and makes for better damage control by limiting what can be broken if done right, but like the article said this is not what it's actually all about since noone seems to care about these points.