I don't think this is true at all. There have been many times where I've estimated numbers to come up with a "scale" number ... which was important in other ways. How many servers are we likely to need? How many connections per second are we likely to see? How much memory is this likely to take up. Depending on the context in which you need to know the answer, estimating a value can be extremely useful. It can point you towards the right "group" of solutions that you should consider.
You realise that that's a very strong (and probably wrong) statement? Those two abilities are obviously distinct, but quite probably positively correlated. So while there are be better interview questions, the answer to this question tells you something about the candidate.
The real problem is that the ability to come up with a good napkin math estimate for a technical problem doesn't correlate with the ability to actually do the job to solve the problem.
Ability to estimate doesn't imply engineering/programming skill. You still have to evaluate that part somehow (coding, take home test, github contributions, etc).
It also tells you nothing about the candidate's ability to work with others, under pressure, collaborate in a team, and all sorts of other "behavioural" interview questions.
Once you spent enough time to evaluate someone's behavioural skills, and also their technical skills, you don't have any time left in an hour interview to evaluate their napkin math skills.