AppImage is basically a runnable .zip file. It contains a loader and an application with all of its dependencies, packed into a single file. If the image was uncompressed, basic extent-based deduplication could save space, but as far as I know the compressed AppImages just don't match up the files like that.

I don't believe Snap natively offers any deduplication. Snap also uses compression (squashfs as far as I can tell) so deduplicating filesystems are equally powerless.

Flatpak has its own deduplication system (that will confuse df/du if you try to run it and often leads to confusion about download time). Through tools like https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker/ you can check how effective the dedup process on Flatpak is. On my machine, Flatpak is using 10.5GB of disk space, but reports 13.75GB of files. Running duperemove on /var/lib/flatpak found two identical extents (belonging to cached files) that didn't get deduplicated already.

As for why they couldn't be unpacked: I don't know. They'd take up more disk space, I suppose. Many standard Linux file systems don't have any form of deduplication mechanism built in, so I'm not sure what the balance would be. I would appreciate the ability to decompress AppImages/snaps without writing custom wrappers for them, but if you're on ext4 like many (most?) Linux users, you'll only see the downsides.