I don't see why AppImage wouldn't be able to be updated if support for this would be added to the app itself.
When trying to download software that doesn't exist in my distro's repo, I always look for AppImage first.
- No sandboxing
- Doesn't solve the "run everywhere" problem, AppImages usually are compiled agaisnt Ubuntu LTS's, which isn't 100% binary compatible with other distros, e.g. fedora
- Its a game of bingo whether the AppImage has a library bundled or not, and whether the app will work your host version or not.
- Performance, appimages are a compressed filesystem that getss mounted by fuse each time the app is run, which is slow, additionally subsequent launches of the app aren't even faster because we get fresh inodes each launch.
- Bad system intergration, appimaged is an abomination.
- AppImages promote a bad security practice of marking binaries from the web as executable, let's not replicate the main way malware is distributed on Windows.
Also last time I read the OP article the tldr is "Flatpak has security options but many packages turn them off making them exactly as secure as appimage/binaries from a package manager"
https://github.com/AppImage/appimaged
The main problem with AppImages is that there is no easy way to update them in bulk.
I can also imagine some possible ways to allow appimages to auto update, though I suspect there'd be a lot of resistance to that.
Also in the future I can see apps being built to actually use the permissions system in flatpak so it doesn't have to be disabled. Flatpak is a step forwards for linux where as appimage is restoring bad practices from windows.
Also, from the research I have done (which I'll admit is inadequate), the process of building an appimage seemed more straight forward than either flatpak or snap.