I tried to investigate the problem of mounts taking longer than expected, left some notes right here: Snapd causing lengthy boot time? It’s not clear why the there is anything in the IO queue of the device at this point.
The mounts are carried out by systemd by invoking mount, which does automatic allocation of a loopback device and associated files with newly obtained /devloop*. Last time I investigated this, I concluded that if there are multiple loopback mounts happening in parallel, there will be quite a lot of contention and respective mounts could end up stealing devices from each other, making the other mount process request a new device and so on. Meaning, that if you try to mount a bunch of files via loopback devices, you will quite likely see the same slowdown.
That being said, automount on demand would be nice, however, the last time I discussed it, there were reliability concerns. I was told that snapd (then snappy?) started with automounted snap images, but that got abandoned due to instability of the software stack. Now, years have passed and many bugs were fixed in systemd, kernel, libmount and snapd itself, so maybe things could actually be improved now.