I think the answer is the dynamic environment. In terms of syntax and semantic constructs Ruby is not very much like Lisp at all. But the dynamic runtime is very lisp-like. You can modify any part of the environment at runtime—in fact there is really no distinction between run-time and compile-time.

IMO the biggest flaw in Ruby is that it doesn't really take advantage of this design choice. Of course there is a performance cost to this kind of dynamism, and all it really buys you in Ruby is the ability to monkey-patch other people's code (the advisability of which is debated). In the Lisp world you have tools like SLIME which provide a much shorter feedback loop to the developer by connecting the dynamic runtime to the editing environment.

Tools like pry move Ruby forward in this area but it is still nothing like SLIME. My impression is that the weakness of Ruby's module system, along with heavy use of OO classes, make it unlikely for Ruby to ever support that kind of development process.

(There are other examples of Ruby's Lisp heritage, such as everything-is-an-expression and implicit return values, but I think those are relatively small design choices compared to the runtime thing.)