So in an interview, I would probably try to guide the interviewee to explore some of these things. "Okay, that's a good first pass. Have you taken a look at all the example cases we started with, will your code handle all of those correctly? Can you think of any other input for this function that might return surprising results? Is there a way we can verify that we've covered all these edge cases? Oh, and what was that you said about unicode support? Can we just dig into that a little..."
Seems like we could find out plenty about how a candidate thinks and codes by pursuing this line of questioning. So long as the candidate doesn't respond to these questions by saying "Look, this is stupid, I'm not going to dig into requirements, that seems like I'd be trying to game the interview. This is my final answer - it tests palindromes. Next question.".
That is not nitpicking, it is the entire point of the exercise. Writing the wrong code is not helpful. The article is very clear how meeting the spec is the most important thing.
This function is too simple to expect anyone to ask you any follow up question regarding the "spec" unless they are trying to game the interview.
Also note that the duct typing properties of JS are often used to allow such string/array ambiguities.