Odpověď na názor

Neházel bych ty všechny zmíněné technologie do jednoho pytle a vyvozoval z toho obecné závěry.

AppImage je opravdu specifická věc. Jak už jsem tu psal, je to vhodné pro portable aplikace, protože se to dá spustit odkudkoliv bez dalších programů v systému - to je hlavní cíl a benefit ("Linux apps that run anywhere").
Nicméně to neřeší problémy, co můžou nastat při případném linkování na konkrétní verze systémových knihoven. Zároveň je to pouze standard pro formát, vytváření a sestavování těch obrazů. Nemá to žádnou formu sandboxování.
Není žádný standardní (oficiální) mechanismus, jak je automaticky aktualizovat, spravovat, integrovat do systému atp. - je to mimo rámec toho projektu na portable aplikace. Jsou možná nějaké horší či lepší utilitky třetích stran, co se o tohle snaží a například extrahují metadata, vytváří XDG desktop soubory (aka zástupce). Může tam být interní aktualizační mechanismus v zabaleném softwaru, co ale logicky nezafunguje, když je image na místě, kam uživatel nemůže zapisovat atp.

Použil bych to pouze pokud není žádná jiná alternativa (Flatpak, Snap, dist. balíček).
Kdyby to mělo popisovaný problém, řešil bych ty aktualizace sám pomocí nějakého skriptu (který má právo na zápis), anebo v případě jediné aplikace bych se tím vůbec nezabýval a normálně to rozkopíroval do všech profilů (~/.local/bin/), ať se to každému uživateli aktualizuje samo pomocí interního mechanismu.

Flatpak oproti AppImage řeší spousty dalších věcí, dá se říct, že to nejen formát a nástroje k sestavení, ale i komplet balíčkovací systém včetně uživatelských nástrojů, sandboxuje, drží se XDG standardů atp. Je tam jistá forma deduplikace pomocí linků. Sdílené runtime balíky šetří jak místo, tak velikosti stahování. atd.
Stran toho delegování administračních úkonů, např. aby běžný uživatel mohl aktualizovat také systémové flatpaky, tak dá vše systémově řešit pomocí PolicyKitu.
Jsou tam registrované všechny potřebné akce, takže stačí např. použít systémovou skupinu users, kde budou všichni uživatelé a napsat jednoduché pravidlo, co ty akce povolí.
Nebo založit novou (např. flatpak-adm), upravit pravidlo a přidat do konkrétní uživatele.

msmucr@msmucr-desktop:~> pkaction | grep -i flatpak
org.freedesktop.Flatpak.app-install
org.freedesktop.Flatpak.app-uninstall
org.freedesktop.Flatpak.app-update
org.freedesktop.Flatpak.appstream-update
org.freedesktop.Flatpak.configure
org.freedesktop.Flatpak.configure-remote
org.freedesktop.Flatpak.install-bundle
..
org.freedesktop.Flatpak.runtime-install
org.freedesktop.Flatpak.runtime-uninstall
org.freedesktop.Flatpak.runtime-update
org.freedesktop.Flatpak.update-remote

Snap řeší hodně podobných věcí jako Flatpak. Byť jsou tam samozřejmě funkční rozdíly.. a každý z obou může mít určité výhody proti tomu druhému.
Osobně mi přijde citelně pomalejší než Flatpak, a to jak na spouštění (komprimované image, inicializace služby po startu), tak i aktualizace (differenciální přenos - delty vyžadují jejich výpočet na klientu).
Navíc je to tak divně mezi - v Ubuntu se to používá jak na desktop aplikace, tak poslední dobou na některé systémové služby. Což mi přijde zbytečné.. specificky v situaci, kdy je jsou na služby zaběhnuté Dockery a OCI kontejnery s bambilionem nástrojů okolo. Podobně to má tvrdou vazbu na jediný repozitář (Snapcraft od Canonoicalu).
Za mě by bylo optimální, kdyby se s tím ještě chvíli vyblbli a pak se to přirozeně odložilo (podobně jako Mir, Upstart) :), aby se zbytečně nefragmentovaly používané formáty pro tyhle desktop kontejnery a zůstal opravdu jeden majoritní.
Koneckonců i na Ubuntu instalacích obvykle Snap deaktivuji a používám tam Flatpak.