I have no idea what those values are! I am still able to make guesses to show that I can figure out a bunch of variables that affect the final value. And since I am multiplying data that's off maybe even by few orders of magnitude, errors multiply as well: I am aware of how erroneous input data affects the results too.
Is it relevant to software development as a whole? It definitely is.
You've got to provision web workers for new service being developed: you can only (guess)timate number of expected users, you can guess how much CPU time each request will take, figure out cost per unit, look at bandwidth requirements, and make your pick. To improve on your guess, you actually go and measure request times (p50, p99), decide on the number of users you can sustain with your team cost effectively, measure network usage, etc.
Or you need to decide on what type of DB to use? Depending on access patterns (read heavy, write heavy, time series...), data size and scalability demands, team familiarity with different tech, you make a guess at what should work: you can only measure after you've got the system exposed to real, live load.
Now, I still think it's a bad interview question: people can be perfectly comfortable answering above questions, yet not see that they are in abstract exactly the same as the number of piano tuners in NYC. It tests for that generic and general ability to estimate anything, and to break down any problem.
Yet some people get flabbergasted (like you seem to do?), since they think too much about specifics of each of the numbers they use and how wrong they might be. Basically, they have a hard time of letting go of the inaccurracies :)
As such, it's a mixture of tests: supposedly only tests you problem breakdown skills, but in reality tests your confidence in using inaccurrate numbers or lack of problem domain knowledge to solve a problem.
Which makes it a bad interview question unless both of those is what you want to learn about someone.