I typically use it as a barometer for how in depth the candidate tries to understand underlying mechanisms of tools they use.
I don't think I'd work successfully with people who don't care.
Another way of thinking about interviewing is this: you say you don’t want to work with people who don’t care about this problem you care about. That’s fine, I guess. But if you changed your viewpoint to “I want to work with candidates who care about interesting things” then you might find you ask more about what they care about and less about what you care about.
Sometimes I'll tell a rebase person that if they don't like merge commits they can use git log --no-merges and you won't see merges. The majority of people I come across who prefer rebase for "clean history" reasons don't know this.
If you truly understand the difference between rebase and merge you'll come to the conclusion that it doesn't matter what you use.
I'd file this question under "trivia the interviewer believes correlates with performance".
Like, asking what a for loop does wouldn't give you any real positive signal, but if they can't answer it's a strong negative signal.
You might as well judge people on how well they know xkcd comics or VIM keystrokes.