So, if the server is hacked, or a DNS is spoofed, you cannot make auto-update pull broken/malware binaries.
The problem is that, if your update process is buggy in some release, you loose those users forever...
validating your updates via asymmetric crypto can be mildly expensive (http://www.verisign.com/code-signing/content-signing-certifi... lists Windows Authenticode certificates at $400/yr) but is within the realm of a small company.
setting up a Google-scale CDN and writing a reliable push update framework? that's the hard part.
That's VeriSign for you. Thawed sells the very same certificates for $200, and Comodo runs a coupon deal for Tucows members that gets you the cert for $99 (though the actual process is a bit too contrived compared to Thawte's).
update verification is a < 100-line block of code using system cryptographic libraries on Windows.
for Chrome-style background updating, the solution is as simple as:
1) running a thread in the background to ping an API to check when updates are available, 2) downloading them via HTTP when they arrive, and 3) having a program which gets run at update-required-exit, which verifies and applies the patch to your main executable.
yes, writing update machinery for your software is some work. no, it's not insurmountable, and will certainly get easier as the Mac App Store and Windows Store gain traction because they allow you to piggyback on the update machinery of the platform.
I'm very wary about auto-updates that pull executables (as opposed to merely data) in this way. It's one thing for Chrome to do it, I assume Google does it in a way that's safe. But freeware/shareware projects? Not so much. Hell, who's to say the authors don't lose interest in two years and let the domain expire. I had one freeware or open-source app that didn't even have the courtesy of asking, it just pulled fresh binaries and restarted -- ouch. (At least you could disable this feature in the preference.)