Because yeah, by hand, even deploying my webapp would take a couple hours. it took me maybe 8hrs of labor to setup my deploy script but given as I've deployed maybe 50 times so far it's paid off.
For me, that would be:
1) provision VM
2) configure the new VM (security hardening, install utils)
3) download app from git and configure it
4) take image of vm
5) install new image into my autoscaler
6) hot-replace live instances of previous version with new version.
doing each of those commands by hand and waiting for each to complete could easily take 1.5 or 2 hours of work. I did it by hand the first couple times but once I figured out my workflow I automated it (bash script) as fast as possible.
I spent a couple days looking into ansible, but as I have a very specific need I didn't want to spend 2+ weeks adding another chunk of "technical debt" to my product.
You can automate all steps for building an application but the signing to make your life easier. You can also automate things locally if you're worried about what you're signing.
The bottom line is that this applies to all apps (though your users might be irritated if they need to keep downloading updates).
Receiving daily updates for desktop apps would suck because it typically requires the app to quit and start again. A good compromise would be updates every four weeks. At the same time you as a developer always leave your app in a state were you could push an update anytime. So you still work incrementally in daily units of work.
Daily updates for libraries … if it's only publicly available code, I don't see a reason not to push daily. Anyone interested can check the commit logs. For compiled binaries on the other hand I can see update fatigue for users (other developers). Once a month or longer seems fine.
In the end, push regularly (daily, weekly, monthly, whatever fits you) without annoying your users by spamming them with updates, while at the same time reduce work units to a size that does not feel overwhelming.