To add to what @Spencer said - in my experience, yes, things that were installed as snaps will run fine without snapd itself running. You can experiment by simply disabling the snapd service (systemctl disable snapd) and seeing how things look. If you check the system logs you’ll see that all snaps (the squash .snap files) are still mounted under /snap, and all services that are installed by snaps are intact - because those are all installed as systemd units at installation time, and will persist even if snapd itself isn’t present at runtime.
What will definitely not work without snapd is things like refreshes (and installs, uninstalls), and many (though not all) of the actions you can invoke through the snap CLI.
In practice, we’ve had systems in the field where snapd itself has become unusable (e.g. because state.json has got corrupted - see https://forum.snapcraft.io/t/snapd-cannot-run-daemon-cannot-read-state-unexpected-eof/), but the snaps themselves have continued to run fine.
This is based on my experience with snaps installed on Debian, which does not have AppArmor (and therefore no snap confinement). The behavior may be different on Ubuntu Core or another OS.