From the perspective of an interviewer, a big problem is that it's much easier for a candidate to BS you with a hand waving design issue than with raw code. You can hide a lot of ignorance behind an insistence on big-picture design issues. If I have 45 minutes (max 1 hour) with a candidate then it is worthwhile spending one or two minutes checking the fundamentals using this style of questions.

I sometimes compare this focus on fundamentals to the game of Go: strong players have a very strong sense of "direction of play" (i.e. strategy), but the way to get strong is to study life&death problems, and tesuji: the intricate tactical issues that weaker players ignore in favor of "power" moves (which work only against similarly weak players)

Of course, it depends on the resume. If you say "Perl expert", then I consider the questions fair: you should at least be able to get the answers wrong. If instead you claim "Ruby expert" then I wouldn't ask the same questions: I'd probe more for the ability to pick up new languages (hopefully such a candidate would know more than one, so I could find some common basis).