I was reading a comparison of AppImage/Snap/FlatPak and it seemed to imply these containerised apps should be smaller than "traditionally installed" versions

I don’t know much about AppImage but with Snap/FlatPak that idea is that dependencies are bundled together with the app, intentionally bypassing your distro’s package management and file system layout conventions. This allows apps to be installed on any Linux distro. Moreover, developers do not have to worry about dependency hell. In other words, there’s no way these apps will be smaller than traditionally installed versions as each Snap/FlatPak will ship its own dependencies. Updates might be smaller though as updating an individual app doesn’t mean updating every other app/package that depends on common dependencies.

Personally, I’m in 2 minds about those new package formats. Aside from there being yet again 2 (3?) competing solutions to solve the same problems (bike-shedding) bypassing distros’ package managers is both good and bad. Sometimes distor package managers do a bad job packaging other people’s software. Recently, I read a blog post about that by some OS dev who suffered from burnout due to people overloading him with problems caused by their distros’ bad packaging habits and the choice to not upgrade when they really should instead of badly back-porting some fix they hardly understand. Can’t find the link at the moment unfortunately. On other hand, devs choosing to ship something rather sooner than later more often than not results in broken software and one ends up installing lots of upgrades every day. By installing apps via Snap/FlatPak you end shifting trust from package managers to individual devs effectively. I don’t know who I trust more. It probably depends on the app/package.

The problem is, this works both ways! For instance, Debian and thus Ubuntu usually freeze a lot of packages and only allow security back-ports. Given that security exploits can be fairly complex involving multiple channels  it happened more than once that pinning a “core” lib to a particular version number results in a whole lot of issues. As package maintainers package *a lot of* software one just can’t expect to always get the most up-to-date release with all the security mitigations baked in