I don't completely disagree with you, but a part in me wonders. Ruby isn't a conceptually challenging language - it doesn't introduce any new ideas that you wouldn't have known by coding a combination, of say, Lisp, Perl, and Python. So if you have an all-around strong candidate on your hands that didn't write a line of Ruby in his life, would you pass? I generally prefer candidates that can reason about language design issues - if you can hold your own in a discussion about whether objects or closures are more primitive, can code well in one or two unrelated languages, and can reason about algorithms in the abstract, it's extremely likely you'll have no trouble picking up Ruby within a very short period of time.
Of course there are exceptions where you need domain expertise, but I find these situations to be very rare. I'm actually thinking that asking the candidate to design the structure of his own interview might not be a bad idea - you can probably learn a ton about the candidate and avoid the trap of hiring clones of yourself.