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.
Both interview processes suck.