It's very clear in the interview that knowledge of chess isn't being tested. The chess-related exchange is literally about 30s and it's clearly part of the segment where the problem is explained, not the part where the candidate needs to demonstrate their abilities.
As for why, by relating the question to something in the real world (like chess or GPS) a few things are accomplished:
- It gives the candidate an ambiguous situation that they have to navigate away from (e.g. by asking clarifying questions).
- It requires the candidate to map a real-world situation to an algorithmic solution, rather than just being told "implement a graph traversal" or "use dynamic programming to solve this".
- It makes the problem more interesting.
I know exactly what it's like to be on the other side because I was there too not so long ago, solving interviews just like this. I found questions like this much nicer than more obscure questions like Gray code.
I think you're just fixated on this idea that the interview is there to test what you know and not knowing something is a fail but that's not really how it works. What a candidate knows is next to nothing to me, what's most important is how they go about solving the problem. Do they ask questions? Do they consider alternative solutions before digging in? Is their code somewhat readable?
Aside from the basics of CS, I really don't care what they know and that's made reasonably clear before the interview (as it was to me when I was interviewed).