Puzzle-based interview questions are meant to be a rough cut to weed out the people who are clearly unqualified for the position. They're not meant as a substitute for more in-depth discussion of skills, work experience, etc. If the filter is too time-consuming, it's going to weed out some of the best people who are confident they'll get offers from other companies. And a large company like Facebook doesn't necessarily want to test specific skills because they may not have yet decided which position you'd be hired for, and in any event you're likely to work on multiple projects during your time with the company. For entry-level positions (which is presumably what these questions are designed for), it's better to hire the smartest guy you can find and train him on specific technologies than to hire a guy who already has a specific skillset and then discover he's a one-trick pony.
Because they want you to be good enough to do it without that.
(I'm saying this as an about to be new grad who is studying these subjects to not have that much help and have to do it on a whiteboard in an interview
and also working on these puzzles and similar ones from a lot of other companies)
Dealing with things in the abstract, stripping it of context, interface, interaction, and real world requirement, seems to be an incomplete way to understand the capabilities of the person you're potentially hiring.
Unless, of course, you're hiring for the position of Junior Abstract Puzzle Solver. In which case, by all means, Godspeed.
Why not give me a real world use case, with a code base to work off of? Put up a codebase on github, provide a set of user stories and requirements to satisfy (ie, "add a real time search using this data set and code base which works cross-browser and degrades in IE"), and ask me to add it, thus basically mirroring a normal development process.
As someone who has had to interview programmers before, that would tell me infinitely more than their ability to re-iterate the word "Hoppity" on the command line.