I guess the point of the author is that no language can have a debugger as powerful as Smalltalk's, as having the code, the state and the tools live in the same environment is the only way you can go as deep as Smalltalk debuggers go.
If you're editing your code in an editor, running it in an interpreter and storing the state in your RAM, there's no way your editor is gonna be able to stop at a point of your stack to let you modify a piece of code live, or add a method, or override an operator, or change the class of a living object and continue as if nothing ever happened.
It might not be as polished as the Smalltalk tools yet, but there's no inherent problem doing this with Ruby. There might be some things you can't do in pure Ruby, such as perhaps replacing a class pointer to actually change the class of an object, but low level hackery like that is easily enough done with a small C extension - I've poked around in MRI's C-level view of the object model before and it's pretty simple.
If you're editing your code in an editor, running it in an interpreter and storing the state in your RAM, there's no way your editor is gonna be able to stop at a point of your stack to let you modify a piece of code live, or add a method, or override an operator, or change the class of a living object and continue as if nothing ever happened.