That's at minimum a day's work for most tasks, and sometimes two if setup or debugging turns out to be more difficult than expected. It definitely doesn't scale as an in-person interview, but by doing it asynchronously you lose a lot of the live communication and thought-process data that current interviews provide…

…then again, you could take this opportunity to measure their ability to give asynchronous status updates instead: can they clearly document their progress, the challenges they faced, and how they overcame them?

My three favorite evaluation processes so far (from the POV of the interviewee):

1. Quick phone screen with someone technically competent enough to call me on my BS if it were painfully obvious, followed by a "come in and let's get you working as a contractor".

I went through this scenario twice, and both times it worked out rather well. Of course, there was risk involved with both parties, but it seemed to work fine for both a 5-person startup and 100-employee agency.

2. Phone call to talk generalities and big picture, followed by a lunch meeting that doubled as a conversational technical interview, followed by a take-home exercise on a paid-for-time-if-no-offer basis.

I went through this scenario once, and liked it even better. The idea behind paying me if no offer follows was that I could be (and was) given a real problem the company needs solved (small, fairly standalone feature in my case) that I could work out for them for a reasonable fee. They'd get full rights to the work, I wouldn't feel like it's a waste of my time if nothing comes of it, and it would all be nil and void if I were offered a job in the end.

3. Quick 30-minute phone call with a few team members to get a sense for what the position, team, and I are all about, followed by a 5-hour marathon in-person interview, but broken up into more digestible chunks: 45-min chat with one of the leads, 45-min chat with someone more on par with the position, 45-min whiteboard problem, 45-min session of actually solving problems at a real computer (while being encouraged to do it the way I would, using Google, Stack Overflow, asking them things as I would ask coworkers, etc.), etc.

This last one was at a BigCo in the Valley and I felt was a pretty damn solid way to go about it. I actually basically bombed the whiteboard problem, but didn't feel like it was an unfair question to ask me, as the single interviewer present was more interested in my process than my reciting a memorized answer.

And, for what it's worth, the peg game problem sounds to me like standard interview fare: an interesting puzzle that bears little resemblance to real-world software challenges. Why is it a better alternative?