Like any tool, they can be extremely helpful, or extremely dangerous. A power drill will make your life so much easier - until you drill through the top of your hand and land yourself in the ER. The same is true with programming challenges in recruiting.
The Good: This may be an effective way to detect someone who, on paper, might not be all that compelling as a programmer. The one with a degree in something that has very little to do with what people normally consider "programming" related fields - Biology, Political Science, Art History...
If they blow through your challenges, then great. They learned programming, somehow, and it's apparently stuck. If they get bogged down, their application may really just be something that slipped through HR.
The Bad: A poorly written programming challenge doesn't actually assess programming skill. It tests puzzle solving via programming skill. The problem is the later is a two variable question - are you good at puzzle solving, and can you do said puzzle solving via code. It's possible to have a perfectly talented programmer who utterly fails at the puzzle solving part.
Most programming challenges I've seen also fail at detecting people who are close to what you want, depending on how it's written.
There's ways to mitigate both of those. For the latter, I'd consider accepting "partial credit" in the form of solutions that don't seem to quite be getting there, "Here's how I would solve this..." etc. if you're genuinely looking for problem solvers. After all, very few people code all alone, and if their answer would have been right if they could ask a senior colleague "Hey Jim, do you know a good way to implement X?", that may very well be someone you want on your team.
The former is somewhat harder, because the burden for that is on you. Pick puzzles/problems/challenges that matter. If no one in your group has ever come up against anything even remotely resembling the Traveling Salesman problem in their work, don't make some clever spin on Traveling Salesman the challenge you come up with. That way, if they're failing at the problem solving aspect of "solve the problem and code it", they're at least failing at something that will actually come up, rather than some arbitrary bit of cleverness your team spitballed over lunch.