Data flow analysis will certainly predict a fair number of types in typical programs in dynamically-typed languages, but there will also be lots of cases it can't handle. I don't know the details of the CMUCL/SBCL type inference algorithm, but I've worked on whole-program data flow analysis, and there are still lots of types it fails to recover, for various reasons. Often, for example, the entire program is not available for analysis; if one doesn't know all the places a particular function can be called, one can't soundly infer all the types it might be passed. Nonetheless, in practice a given parameter of such a function is normally passed arguments of a particular type (or subtypes thereof), and frequently, clues such as the parameter name can help one take a pretty good guess as to what that type is. Since such a guess is sometimes going to be wrong, it can't safely be used for optimization, but it can be very useful for other purposes, such as analyzing the program to find potential security vulnerabilities.
DFA isn’t usually used in type inferencing algorithms, at least ones that generate types for programmers rather than compiler optimizations. It isn’t that it is expensive, but in general syntax tree walking works well enough.
Whole program analysis is too expensive for type inference (or much of anything for that matter) even with its precision ramped all the way down via something like CFA0. Type inference with sub typing is a very similar problem to alias analysis, which hints at why doing it in any but very restrictive contexts is too expensive.
If you don't need perfect soundness, whole-program 1-CFA can be made practical by heuristic pruning. I've done it successfully in a commercial static analysis product.
It can still be used for optimization in many cases depending on the language, e.g by generating specialised versions and shunting calls from known call sites to the specialised version when you can either guarantee the guesses are right or cheaply lift guards up the call stack.
