It seems like this would do well on Python code where type errors are relatively rare, and the developers' attitude towards types has been basically sane for the history of the project. Furthermore, this looks like it's going to work best if you have a lot of pure functions. If these things are true you're already doing pretty well! I'd say this is a tool to make already-exemplary Python code even better.
However, my main use for this so far has been for old python 1.5-2 programs (some 15 years old) with not much typing at all. Adding limited type information for methods seems useful for helping the static checkers as well in these cases. The division errors in the blog post were based on real bugs it found inside class methods for example. I bet there are lots of corner cases I haven't tripped over yet however. I wouldn't be surprised with dynamic python that it could cause quite a lot of problems. Python can get pretty fancy. I told it to ignore all 'self' variables for example.
I think basing it on the coverage tool helped avoid a lot of problems. Because they have already done the hard parts of getting the tracing to only happen on user code. If you don't trace into libraries, and only do user code the task becomes 7 million times easier.
