Generally speaking yes there is a cost that is due to the compression, but only for certain classes of applications.
I actually did a more thorough review (which led me to develop etrace) on compression and dynamic library loading on snap application startup here and here. Also note that I did measure the effect of no squashfs overhead via snap try, which is detailed in the former post, and there is a small difference between snap try and a squashfs with no compression.
TLDR, for apps that ship a lot of dynamic libraries that the main executable depends on, there will be a more noticable slowdown in the time it takes for them to show a window, primarily because these dynamic libraries all need to be decompressed before the application runs. Apps like games that are very large but do not need to load many large files just to display a window to the user seem to launch quicker because they can decompress all the rest of the files from the snap in the background after the main window has been shown. There is also some slowdown from dynamic library search paths, but this is less significant than the compression effects and requires more snap packaging work to implement a fix for.