One of the things Michael mentions is how static analysis can find defects on paths that are rarely executed. An example is error paths. Many error paths arise because of a failure in a low level library. The failures at the library level are often nondeterministic and/or difficult to reproduce, because they depend on external conditions such as a network disconnect, disk failure, OS resource exhaustion, etc.
Static analysis tends to find a lot of defects on error paths when analyzing mature code. The reason is simple: non-error paths are executed much more frequently, and most bugs have already been shaken out through testing. The error paths are typically less well tested, and therefore have more low-hanging defects for static analysis to find.
The situation with new code is different. Since static analysis can run fairly quickly and automatically, it's quite feasible to have it run as part of an automated system to catch new defects before longer-running testsuites could finish. In this case static analysis can find defects on frequently executed code paths, and that can be quite valuable to avoid tracing the root cause of a defect backwards from a failing test.