I've been using an AppImage of Thunderbird 45.4.0 since 2016 with success, for example. I also use AppImages for gimp, libreoffice, and imagemagick, among others. Basically, if an application is complex (i.e., has GUI and/or vast dependency tree) and deals with very mature protocols or filetypes, then I'll use an AppImage for it.
An AppImage is a squashfs of an application plus all its dependencies, coupled with a little C utility that mounts the squashfs (using fuse) and launches the application. The main downside of AppImages is their large size (e.g., 161 MB for gimp, 268 MB for libreoffice), but that is the price to pay for bundling the entire dependency tree.
If an AppImage exists that you like, then that's great. So far that's yet to happen for me.
A while ago I wanted to try out a program that required Qt 6, which no distro I'm running has available. I installed a recent Ubuntu on a VPS (so I didn't have to download many things over my limited home internet). First I tried to build a static binary, but it turns out you need a commercial version of Qt for static builds to work (yet another reason why I dislike Qt). So I tried to build an AppImage. Very long (228 lines of notes) story short, it took a
hours of manual fiddling with the parameters to linuxdeploy (I also tried appimagetool, but didn't work for me at all) to get something that
half worked. I still couldn't get the program to use the AppImage-included OpenSSL 3, so any functions requiring encryption failed because TC14 only has OpenSSL 1.1.1. Which is exactly one of those awkward version problems (OpenSSL seems to be very good at creating them lately) which AppImages are meant to solve!
Many AppImage developer's guides suggest building AppImages on older distros, which wouldn't use new versions of libraries like OpenSSL 3 and therefore only people on even older distros would encounter such problems. But old distros don't have Qt 6 packaged, so it's a catch-22.
Lesson learnt: If nobody's made an AppImage already, it's probably because it's just too damn hard to do so.
Static binaries are still better than AppImages in my optinion. I use them for pandoc and fsarchiver. But they're not always possible to build for complex software.
Pkgsrc isn't going much better. I wanted to use the binary packages available for either RHEL 7 or Slackware on x86_64, but binaries from either of those sources won't run on TC 14 Pure64. The dynamic linker (/lib/ld-linux-x86-64.so.2) doesn't seem to like them. With the RHEL 7 ones it says it can't find a shared object file, but the name of the shared object is blank and I don't see anything missing with "ldd". With the Slackware ones, both /lib/ld-linux-x86-64.so.2 and ldd return "Bus error".
So the only option is compiling from source using pkgsrc's automated system, and so far that's proving slow and error-prone. Probably no easier than compiling manually and building TC extensions. Certainly not a quick way to try out newly discovered software and see if it's useful, which is what I was looking for.
So my only answer is static binaries, and when they're not an option it seems it's just tough luck!