I disagree.
Systemd did things differently, sometimes annoyingly, but the intention was still to allow you to control your own system. It also ate other projects (e.g. udev) and sprouted features (resolved, timedated, etc.) making it difficult to untangle, but it was/is still possible to do so.
The biggest complaints I see about snap as currently implemented are related to making arbitrary outbound network connections, automatic updates that you can't disable, and inability to mirror or vendor snaps or an entire archive / repo.
These don't seem similar to me at all. Systemd is opinionated, perhaps in a non-unix-philosophy way, but still preserves users' freedom. Snapd does not.
If you have a system with snapd, your system is doing things that you can't disable without replacing the system wholesale. The Microsoft-levels of telemetry and lack of control seem to me clearly worse in every way than anything that was ever wrong with systemd.
I don't actually believe that snapd is irredeemable, and think that these things will eventually be fixed, either as they progress on their roadmap, or as a response to user outrage. But I don't really understand how it got shipped in such a state. In particular, the non-disableable silent updates seem to me like a complete non-starter for a server operating system. How are you supposed to schedule maintenance? What were they thinking?