I wonder why you lost or never had any faith in static analysis. On Apple's platforms it's becoming a really big "thing". Also John Carmack talked about the benefits of static code analysis at QuakeCon 2012.
I'm a big +1 for static code analysis as a "silent observer" of code practices. We have various static checks run on each build and if a certain threshold is crossed, the build will kick out an error (we've decided not to have it fail entirely, although some could argue that's a reasonable thing to do).
Although we're a Ruby and JS shop, we take advantage of different services and libraries that perform different checks. In dynamic-language land it's a lot harder to do some of the things that static complication provides, but it's a heck of a lot better than nothing!
I hated every attempt at static analysis until I started programming with Xcode. In my usage, Build and Analyze is always right -- that's the difference. Other tools (lint, FXCop) are too noisy. Even warnings in some compilers are an annoyance that you have to code around to eliminate.
Fxcop is massively overused. The rules are designed for teams who are building libraries and frameworks (thus the name, Fx is short for framework). For ordinary app development many of the rules are inappropriate, which can lead to an impedance mismatch and frustration.
Yeah, I read that Objective-C got it's ARC feature after static analyzer was integrated to Xcode. No more manual reference counting is definitely a plus.
Also a good read: http://www.altdevblogaday.com/2011/12/24/static-code-analysi...