If you are developing a system meant to be stable and run for an indefinite period of time, static analysis imposes less computational overhead. You pay the price of static analysis only once. You pay the price of runtime checks every time you use the checked functionality. Even worse, if a check in the middle of an ongoing transaction fails, you must accept the cost of rolling back the whole transaction. From a purely computational point of view, static analysis is less expensive.

(Of course, this analysis of the situation changes drastically if you take into consideration the overhead on the poor programmers' brains. Static analysis is intellectually more demanding.)

Static analysis of any sizeable Ruby program is at best an unsolved problem, at worst impossible, as a lot of Ruby libraries depend on eval() and tracing down the sources of data for the eval string to verify that it isn't potentially user supplied (and often it can be)is hard enough, and the moment the data may be user supplied, you've "lost": Pretty much anything you thought you knew up to the eval() call can be wrong after the eval() call.

If you need/want static analysis, the option for the foreseeable future is to use another language (and I say this as a huge Ruby fan that also would love to see an evolution of Ruby that'd make some/more static analysis feasible, but for that to happen I believe you need an effort to provide a module encapsulating common eval() behaviour and a huge effort to replace eval in common Ruby libraries - it's not likely to happen anytime soon).