Not all of those views are from objectors, only a few people of those few thousand who have viewed have actually commented or Liked comments to register their opinion (even though I’ve been encouraging people to engage in that way, they don’t always do so), so we don’t know what their opinions actually are, so you can’t claim that that view number demonstrates ‘what users and developers want to see from snap the most’, and many of the comments are actually from snappy devs and myself engaging with objectors rather than making reasoned objections ourselves.
I think I back change here but I get where the devs are coming from and I’ve driven much of the traffic to this page because it’s one of a few places where I think snappy is currently going wrong (but I understand why it’s making this decision and it does have positive consequences, not only negative ones) and I’m honest about snappy’s downsides and want people to try and engage with the devs productively rather than simply get angry about it. Giving specific use-cases as to why this doesn’t work for people (rather than just ‘I don’t like it’) and suggesting changes short of an off switch (since the devs aren’t willing to contemplate an off switch yet) will move this issue, more of that productive input, I think, will create more change 
We’ve already made progress, the snapd refresh timer enables one to just schedule an update once per month. If people can give good reason as to why that should be extended, and to what period of time and why that particular time period, then it may be… I’ve filed a bug against Ubuntu for Ubuntu to surface this option in a GUI, please mark yourself as affected by that bug
Just because you (and many others) don’t like it doesn’t mean it should be changed. Users will always dislike certain parts of software but other users will dislike the change. The protesting voices are usually the loudest so the objectors’ views can’t always be heeded because, if that’s always done, there’d be constant flip-flops in design. Personally I really like the background updates. It’s completely hands-off and lets you get on with your work, Chromium OS-style. And not allowing a global off switch forces developers to get to grips with the feature and develop tests etc to ensure that their updates don’t break people’s experience. As for the changelog, yes that should be available somewhere and easily accessible from the command-line and from software centres. Was this something that came up at the sprint for GNOME Software @willcooke? Would the home screen surfacing of ‘updates from your favourite application publishers’ cover this? Could it be accessed in a more reliable fashion (i.e. on clicking an application, access to the changelogs is there on the application page)?
In theory those new features should be discoverable enough that you’d find them through just using the software but I get the idea. I think updates on GNOME Software’s home screen will help with that.
It’s not an illusion. There’s some risk because the apps are coming straight from upstream and sometimes the dependencies will be out-of-date but, on the other hand, you get updates, often including security updates, as soon as they come from upstream, there’s no distribution middleman delay.
If your connection is metered, snappy will hold back the refresh for up to 60 days, if you think that should be extended then make your case in the topic and give a specific use-case as to why you may need longer than 60 days. Maybe one could be in a developing country and with no Wi-Fi access but metered mobile data access? Is that a real use-case?
I’ve asked if the metered bandwidth toggle in GNOME 3.28 will work with the above feature, if so then it should cover your use-cases above too (and graphically). You can do this with the command as it is: snap set system refresh.metered=hold then snap set system refresh.metered=null when updating is fine.
Personally I notice when snappy is taking up bandwidth when I’m on a low bandwidth connection so I run snap changes then snap abort foo to end the refresh, but the refresh.metered command is neater than that, and the refresh scheduler.
I didn’t think this was possible in Android? Huh.
What if snappy wants to do things differently?
The former is a good point, I’d like to see some comment on that from, say, @niemeyer, perhaps holding back refreshes on particular snaps for that use-case is a good idea? Or maybe they’d have to say that this is something that snappy can’t provide and you need to use something like AppImage or Flatpak instead for that use-case. The latter (‘working file format’) should be covered by the epochs feature which is currently in development (no ETA yet), as I understand it, if there’s an update that changes something like the file format, the dev should give that a new epoch number and you won’t be automatically refreshed to that new epoch? Is that correct @niemeyer? This would cover your Krita, Kdenlive, Inkscape, GIMP use-cases. Your Ubuntu issue sounds like something different 
Once epochs is a feature, if I understand them correctly, that won’t be necessary, everything should just work (though I understand there’s some risk here…I guess the snappy devs reckon that it’s a risk that you should just have to take, sorry!)
Your admin can already take care of that. A feature that has grown out of this topic is the Snap Enterprise Proxy which allows your admin to manage the refreshes! 
Staggered updates is an idea (like how Ubuntu pushes out Stable Release Updates to around 20% of users at a time), @niemeyer? Maybe snapd does this already though, not sure.
That’s usually because there hasn’t been a new release recently In theory it works fine, we just need more early adopters reporting bugs… @popey could possibly comment on this, I can’t recall specific occurrences where an update is pushed to a non-stable channel and regressions are fixed, thanks to user reports, before they hit stable, but he may be able to recall occurrences