I see no reason not to have a hybrid approach. I like signed binaries not because it tells me that everyone who touched it was a Good Guy, but because it lets me know who (or which organization, at least) is vouching for the code. I trust the Linux kernel sources to be the foundation of my security-sensitive systems. That doesn't mean I trust every person who's touched the code, but it does mean that I trust the people reviewing and signing off on the code. And I want to know that my system is running an unmodified version of official Linux (or an unmodified distribution kernel, at least) and not some random hacker-supplied version.
That's where code signing comes in. It tells me that yes, this is the version of FooApp that I meant to download and run, and that yes, it really is from FooSoft.
What code verification does is an extra step to help protect me for cases when I find need to run code from some specific (but not yet fully trusted) software provider. I've never run anything from FooSoft before, but I find myself needing to run FooApp because it is the only software that does what I need. I'm not going to do a full source analysis (be honest, you almost certainly haven't even looked at the source for 99% of the software you run) because I have better things to do with my life. So I rely on code verification (like Google's) along with the positive reputation of FooSoft (and the fact that I know the FooApp I'm about to run really is the real deal from FooSoft) to keep me safe.
I can't guarantee I'm 100%. You can never do that. I might even have a box with no Internet access but my assistant/wife/janitor/whoever might decide to abuse his or her physical access.
ALL security -- be it computer security, a deadbolt, or whatever -- is about risk management. You can never completely remove security holes, but you can reduce the ease of finding them, increase the complexity to utilize them, and decrease the potential damage of abusing them.
Sandboxing, code verification, and code signing all are tools to help manage risk. No one method is fail proof and no one method is better than all methods.