Linux

I daily drive Debian and have a few loose .deb packages and tarballs installed. Also enabled the Librewolf repo. It mostly comes down to an issue of manageability and possible conflicting dependencies. The ones I have installed don't introduce any dependencies, so they've been trouble-free and have survived the Bookworm to Trixie upgrade. They are installed as a last resort option in the absence of a satisfactory equivalent via the official repo, Flatpak, or AppImage.

Loose .deb packages can be installed and uninstalled like any other normal Debian package, but won't be automatically updated and don't have any compatibility guarantee. Tarballs are nothing more than a collection of files, which may need to be placed in system directories. You're on your own for those since there's no standard and automated way to manage them and it's possible to overwrite important system files if unpacked and copied in blindly. It's a good idea to keep a manual record of what was put where in case any issues with them pop up down the road.

My personal ranking:

Official Debian repo > Flatpak > AppImage > Docker/Podman > Snap >> Reputable and known compatible third-party repo > Loose Debian .deb > tarball > Loose Ubuntu .deb >> Unfamiliar third-party repos and PPAs

There are certain occasions where a loose .deb or tarball won't hurt, but sticking to options further up the list closes off the biggest routes of breaking Debian.

Debian is known to be stable as in "staying the same", you won't get any big version updates on the programs in the debian repository, just backported security updates. That ensures that you don't end up with dependency mismatches where different programs want the same library but different versioning.
It also means that as Trixie ages the version you get from the repo will be further and further behind as you will still be running 2025 versions with backported security updates until you upgrade to Debian 14.

By installing random .tarballs and .debs outside the default repository the main advantage of Debian Stable is nulled.
I would actually recommend going all in on flatpaks, appimages and dockers if your goal is to keep the main system stable and lean. You might also wanna look at distrobox for running programs that aren't officially available for your distro.
Another thing too look at is atomic distros, such as Fedora Kinoite https://fedoraproject.org/atomic-desktops/kinoite/

Im pretty appimage is stable to use on your system. It contains all of the dependencies inside of it. Just one file for all of its needs. Only issue that ive had is that you need to manually update them (ie download the newest version).

Other repos and debs are fine, just don't go overboard and add dozens of them. It's actually a better idea than some other methods, because of the ease of uninstallation if there's a problem.

If the goal is stability, I would have likely started with an immutable OS. This creates certain assurances for the base OS to be in a known good state.
With that base, I'd tend towards:
Flatpak > Container > AppImage

My reasoning for this being:

1. Installing software should not effect the base OS (nor can it with an immutable OS). Changes to the base OS and system libraries are a major source of instability and dependency hell. So, everything should be self contained.
2. Installing one software package should not effect another software package. This is basically pushing software towards being immutable as well. The install of Software Package 1, should have no way to bork Software Package 2. Hence the need for isolating those packages as flatpaks, AppImages or containers.
3. Software should be updated (even on Linux, install your fucking updates). This is why I have Flatpak at the top of the list, it has a built in mechanism for updating. Container images can be made to update reasonably automatically, but have risks. By using something like docker-compose and having services tied to the ":latest" tag, images would auto-update. However, its possible to have stacks where a breaking change is made in one service before another service is able to deal with it. So, I tend to tag things to specific versions and update those manually. Finally, while I really like AppImages, updating them is 100% manual.

This leaves the question of apt packages or doing installs via make. And the answer is: don't do that. If there is not a flatpak, appimage, or pre-made container, make your own container. Docker files are really simple. Sure, they can get super complex and do some amazing stuff. You don't need that for a single software package. Make simple, reasonable choices and keep all the craziness of that software package walled off from everything else.

flatpak > distrobox > nix > appimage > brew > .deb

I never installed any gui via podman. Not sure when it applies

If an app has bugs via flatpak, then don't use the flatpak. Maybe it'll be resolved in a year and then switch.

Edit: removed snap from list

Not really answering your question, but what you describe is exactly why I switched to arch and have been rocking the same install for over a decade.

It's uNsTaBLe - I keep getting updates and things keep changing and rarely something needs my intervention to keep working. But it keeps working. And I can install viber from AUR without thinking.

Before that I was on Debian and then Ubuntu and then Kubuntu - and dist-upgrades were a much worse, weekend-destroying, rage-inducing pain than doing light weekly maintaining of my arch install.