My contention is that it doesn't matter if the time limit is unrealistic (within reason) so long as it's consistent.
ie: the challenge is not "Show me the best solution to this problem" but rather "Show me the best solution to this problem that you can achieve within an hour".
As long as everyone is under the same conditions, the playing field is level.
It's part of a holistic approach, too. The coding challenge is not the only part of the interview process. I suggest that there be an initial interview to assess experience, fit, explain the job, etc. Then if everyone is still interested, the coding challenge. The candidate's response to the challenge then forms the basis for a discussion in another, technically focused interview.
It's not about saying "You gave the wrong answer" but "Talk me through why you solved it this way" and "If this criteria in the challenge changed, tell me about how that might change your response"
The Codility and Hackerrank style problems are okay, but I don't like how constrained they are. I also think it's pointless having someone outside your organisation grade the results. What matters is not having a candidate who is "the best hacker" but having someone who fits what you need. If your team values robustness and debuggability above all else, you _don't_ want someone who can punch out 3 kinda-right prototypes before lunch. If you're an ideation agency, the inverse is true.
That's why takehome encourages companies to create and administer their own challenges rather than the samples. They should fit the kinds of problems your organisation faces, not contrived ones.