On the contrary, these are great questions to raise at the start and I'd absolutely rate a candidate better for asking them. Too many of my coworkers solve the wrong problem. They treat the symptoms instead of finding the root cause, and so we end up with a fragile patchwork of dirty hacks that get cargo-culted into other code bases.
That being said, the time spent on these questions should be minimal. It should go something like:
Candidate: It seems like we're solving the wrong problem. Why can't the server handle multiple simultaneous requests from a single client?
Interviewer: Its a 3rd-party server we don't control. (or even just a "because those are the artificial constraints for this puzzle" if the interviewer is feeling particularly lazy)
Candidate: Ah okay. <proceeds to work on the problem>
Sure, that's completely reasonable. But getting hung up on them for an hour is ridiculous.
I also think they're unnecessary in the first place. I wouldn't hold it against anyone in a scenario like you described but I also wouldn't expect it. Solving the task as it's posed is good enough.
I might just mention that my first instinct would be to fix the root of the problem instead of asking about it, I wouldn't expect the interviewer to have spent time world building for their made up task.
That being said, the time spent on these questions should be minimal. It should go something like: