I don't really have a problem with this in general, if a few rules are followed (that Canonical/Snap have apparently not even remotely bothered to address):
0. First off, the user should have to opt in to automatic updates. This should never be forced.
1. The update should never cause unsaved work to be lost. This means that the auto-updater should never kill the application unless it knows that it can start back up in exactly the same state before it was killed. Some apps will do this normally (some requiring configuration first), like Firefox, but others cannot. That's actually something I think apps should be required to have: there should be a standardized "snapshot-kill-restart" interface (perhaps some DBus thing) that allows for this. The old X11 session management system was designed for this, but in practice implementations are always buggy to some extent.
2. The app should be restarted after being updated, especially if it's happening in the background outside of user control.
3. The app should never be killed while the user is present and doing something. It should only happen while the machine is idle. If there's never an opportunity for that (say, the user always puts the computer to sleep rather than leaving it idle), then the update mechanism must resort to popups that ask for consent to do the update right then. The consent should only last for that single instance.
4. Updates can't ever break things. Auto updates should be reserved for security and critical (like data-loss) bugfixes only. All other updates should be voluntary. (I'd reluctantly make an exception for the case where there are security issues that need to be fixed, but it's not possible to backport those fixes, so a "security update" becomes a straight version update. Nothing is perfect.) A big part of why users don't like automatic updates is because they break things or remove features too often. Stop doing that, and users will start to trust the auto-update mechanism again. (And point #0 will stop being an issue: users will be happy to enable auto-updates. And maybe at some point I'd even drop #0 and think it's ok for vendors to enable auto-updates by default.)
Regarding killing apps that need to be updated, most do not need to be killed at all, and can be safely updated underneath the running instance. Yes, there would need to be some mechanism to ensure the OS has paged all of the executable into memory (don't want "Text file busy" errors when trying to overwrite binaries), but this doesn't feel like a huge deal. Some apps do need to be restarted, as they dynamically load and unload UI resources from disk as the user uses the app, and those files changing underneath a running instance would cause problems.
If this was an unpaid, volunteer project, I could certainly understand that the auto-update process would be unpolished and not the best. But Snap is owned by Canonical, and if they're serious about this, they need to get their shit together and actually focus on UX... ironic, since that was originally the entire point of the company in the first place: make a Linux distro with a polished UX that non-techie people would feel comfortable using.
Your set of rules, while reasonable, bear no apparent similarity to how Ubuntu is implemented. In particular it's moderately involved to disable the automated updates and seems to change each time I go through it.
0. First off, the user should have to opt in to automatic updates. This should never be forced.
1. The update should never cause unsaved work to be lost. This means that the auto-updater should never kill the application unless it knows that it can start back up in exactly the same state before it was killed. Some apps will do this normally (some requiring configuration first), like Firefox, but others cannot. That's actually something I think apps should be required to have: there should be a standardized "snapshot-kill-restart" interface (perhaps some DBus thing) that allows for this. The old X11 session management system was designed for this, but in practice implementations are always buggy to some extent.
2. The app should be restarted after being updated, especially if it's happening in the background outside of user control.
3. The app should never be killed while the user is present and doing something. It should only happen while the machine is idle. If there's never an opportunity for that (say, the user always puts the computer to sleep rather than leaving it idle), then the update mechanism must resort to popups that ask for consent to do the update right then. The consent should only last for that single instance.
4. Updates can't ever break things. Auto updates should be reserved for security and critical (like data-loss) bugfixes only. All other updates should be voluntary. (I'd reluctantly make an exception for the case where there are security issues that need to be fixed, but it's not possible to backport those fixes, so a "security update" becomes a straight version update. Nothing is perfect.) A big part of why users don't like automatic updates is because they break things or remove features too often. Stop doing that, and users will start to trust the auto-update mechanism again. (And point #0 will stop being an issue: users will be happy to enable auto-updates. And maybe at some point I'd even drop #0 and think it's ok for vendors to enable auto-updates by default.)
Regarding killing apps that need to be updated, most do not need to be killed at all, and can be safely updated underneath the running instance. Yes, there would need to be some mechanism to ensure the OS has paged all of the executable into memory (don't want "Text file busy" errors when trying to overwrite binaries), but this doesn't feel like a huge deal. Some apps do need to be restarted, as they dynamically load and unload UI resources from disk as the user uses the app, and those files changing underneath a running instance would cause problems.
If this was an unpaid, volunteer project, I could certainly understand that the auto-update process would be unpolished and not the best. But Snap is owned by Canonical, and if they're serious about this, they need to get their shit together and actually focus on UX... ironic, since that was originally the entire point of the company in the first place: make a Linux distro with a polished UX that non-techie people would feel comfortable using.