For one, it has nothing to do with programming. Also, nothing to do with time management, people skills, or anything else that programmers do on their job.
You don't need the exact value, just a rough order of magnitude. That's the whole point of the big-O notation. A problem like that is lighthearted, which has the advantage of removing all of the computery specifics that could bog you down in a realistic question. The ability to pull numbers out of your ass quickly, and still have them be within a factor-of-2 of an answer that would take weeks or months to gather, is critical for a developer.
The ability to guess that is also a good indicator of whether you're likely to be a good culture fit.
One of the reasons I don't like "how many ping pong balls" etc. is that you're wasting valuable interview time. Interview time should be treated as very valuable to all concerned. Asking about ping pong balls just to find out estimation skills is a waste of time because it doesn't raise any other interesting questions, vs asking an estimation question that raises all kinds of other things you can pick up that are actually relevant in addition to testing estimation skills.
If anything, it sounds like "ping pong ball" problems have become cliche. That makes them less useful: it doesn't represent my creativity, and it potentially leads to them reciting rote answers from "cracking the interview" books.
Fortunately, I can come up with a thousand problems off the top of my head. How many letter "e" in the New York Times every day? How many sodium atoms in the ocean? How many people at the Nobel Prize Ceremony?
The more off the wall the question, the more I'm testing how they handle the unfamiliar -- as well as conveying who I am. Which is part of the point. They should be interviewing me as much as I'm interviewing them.
But hey, ask your silly question about sodium atoms. As for "interviewing you" as well, if you're ever interviewing me and pull one of those out, you better be looking pretty good in the rest of the interview because you just lost a lot of points.
The skillset I have that allows me to accurately estimate software projects is based on my knowledge and experience in that domain, and just because I can estimate there doesn't mean I can estimate tennis balls in a building, nor does being able to estimate tennis balls in a building give any indication of ability to estimate software projects.
Anyone that thinks there's some overlap between estimating software problems and estimating how many tennis balls would fit in the Empire State Building is not someone I'd want to work for.