As others have mentioned, the trade-offs can be pretty complicated. Perhaps the take-home is always better for you, I won't try to argue against your personal preferences, I'm simply going to list a few reasons why it turns out worse for a lot of people.
For one thing, as expected, the take-home questions are typically far larger than in-person interview questions. When you go into the office you're generally asked, in my experience, much simpler questions; you might get a simple FizzBuzz-like starter, and a few slightly more difficult ones. All in, it takes a few hours (Google and the like can be an exception to that, but I'll get to that after - I'm comparing smaller companies right now).
The take-home work I've seen has generally been suggested by the company to take 8 hours, but typically been a bit more; they've been along the lines of build a fairly simple crud (I've had one that was a calendar, another that's a stream, etc.) with a bootstrap-or-similar UI, back-end validations, and unit tests for the initial commit, implement these 3-5 features on top of it in separate commits (tested, also standard bootstrap-or-similar UI, proper validation, etc.) And then, simply provide access to the repo.
At first, this didn't seem wrong, in fact I figured "well, I guess it's a good way for them to see that you understand everything". But it came with several annoyances. For one thing, since each feature is a commit, unless you specifically try to prevent it they can see things like how long each part took; even if not consciously, this makes people try to get the work done quickly, without taking many breaks. It sort of reintroduces the "hard to 'refactor' your ideas during a 45m coding interview" problem. Another annoyance is that sometimes (and judging by other comments here, even often) they don't respond at all. The silence is unpleasant, to say the least. In-person, you can at least try to read tone and facial expressions.
The other problem is one company I applied with threw a 10+ hour take-home without any warning before the interview. So a bit over an hour in their office, and another 10+ later. This is difficult if you're working another job. It's very difficult if you have a couple such take-homes at the same time, and a full-time, in office job. Scheduling a few interviews around work, and other commitments, is pretty feasible, but throwing in dozens of hours of additional coding is more difficult.
With companies like Google, you know ahead of time approximately how long it will take. You can take time off accordingly. The process is known going in, and that's great.
Basically, I think that for many people, myself included, white-board interviews are very stressful and frightening, but not quite as much so as: scheduling lots of extra time around your life, budgeting X extra hours because they take longer than suggested, building out the (much larger) projects, still having the time-constraint/expectancy issues, and after all of that not always even getting a message/comment afterward.
There's a lot of truth in what you write and I definetely see the problem.
One solution is to have the take home interview as the final step in the process - after having screened the candidate and discussed general technology/framework/concepts without coding.
When I did interviews, I found that just by discussing things like thread synchronization and let them explain the projects that they've worked on would weed out most of the candidates which weren't a fit with the position.
Then the take-home problem would make a lot more sense for both the employer and employee.
Or another method:
You take home a problem, implement it, then present the solution to multiple potential employers.
The problem would have to be unique (so that there are no ready made solutions online) and trusted by the participating employers.
And I think this is exactly what OP is doing, and that's why it's great.
At the same time, I prefer the idea of presenting previous open source work instead of having a group of potential employers agree on a project that they can all judge. One benefit is that the work is less arbitrary, potentially useful for others. Another is it's more likely to be unique than an assignment is. Finally, do I want to work for any of those other employers?
Applying to a group that way would seem odd to me; part of me thinks that choosing companies is important, but another thinks that there's some chance that that's just because I haven't tried it.
Which, of course, leads me to agree that the OP is great as an experiment - it might well be a better solution in many cases. The fact that, in the OP, it's opt-in is a big deal as well. Though I'm still very skeptical of take-home interviews in general.
For one thing, as expected, the take-home questions are typically far larger than in-person interview questions. When you go into the office you're generally asked, in my experience, much simpler questions; you might get a simple FizzBuzz-like starter, and a few slightly more difficult ones. All in, it takes a few hours (Google and the like can be an exception to that, but I'll get to that after - I'm comparing smaller companies right now).
The take-home work I've seen has generally been suggested by the company to take 8 hours, but typically been a bit more; they've been along the lines of build a fairly simple crud (I've had one that was a calendar, another that's a stream, etc.) with a bootstrap-or-similar UI, back-end validations, and unit tests for the initial commit, implement these 3-5 features on top of it in separate commits (tested, also standard bootstrap-or-similar UI, proper validation, etc.) And then, simply provide access to the repo.
At first, this didn't seem wrong, in fact I figured "well, I guess it's a good way for them to see that you understand everything". But it came with several annoyances. For one thing, since each feature is a commit, unless you specifically try to prevent it they can see things like how long each part took; even if not consciously, this makes people try to get the work done quickly, without taking many breaks. It sort of reintroduces the "hard to 'refactor' your ideas during a 45m coding interview" problem. Another annoyance is that sometimes (and judging by other comments here, even often) they don't respond at all. The silence is unpleasant, to say the least. In-person, you can at least try to read tone and facial expressions.
The other problem is one company I applied with threw a 10+ hour take-home without any warning before the interview. So a bit over an hour in their office, and another 10+ later. This is difficult if you're working another job. It's very difficult if you have a couple such take-homes at the same time, and a full-time, in office job. Scheduling a few interviews around work, and other commitments, is pretty feasible, but throwing in dozens of hours of additional coding is more difficult.
With companies like Google, you know ahead of time approximately how long it will take. You can take time off accordingly. The process is known going in, and that's great.
Basically, I think that for many people, myself included, white-board interviews are very stressful and frightening, but not quite as much so as: scheduling lots of extra time around your life, budgeting X extra hours because they take longer than suggested, building out the (much larger) projects, still having the time-constraint/expectancy issues, and after all of that not always even getting a message/comment afterward.
Both interview processes suck.