There are developers who excel at whiteboarding. There are those who excel at presenting their own projects from their github experience. There are yet others that excel in small code samples on company-driven problems, and some that excel in larger code samples.
The truth is that no one interviewing style works best for finding all developers that are a match for the company. Either we need to accommodate multiple interviewing practices, or we need to accept that we are going to gather in the companies that match our interviewing styles the best.
I wonder sometimes if there isn't room for a company that hires everyone who can fizzbuzz and is a good fit for the company as determined by behavioral interviews, and then accept a large attrition within the first 3 months.
I think the honest truth is that no matter what we do, interviewing is a hard problem.
Why?
The biggest risk with those take-home projects is that you'll lose out on the "2-3 hour project" because someone else spent 5-6 hours and had time not to just finish it, but to make it look very polished—unreasonably polished for 2-3 hours. So you either do it as directed and worry, or spend way more time on it (enough that I'd probably just pass unless it was one hell of a job)
Keep it small enough and you don't run into the thing where you're excluding the semi-happily employed, competent devs, because they don't really have to put up with your shit to find new employment, which is the case with those defined time (but not really) larger projects.
We've hired only great people with this approach, and they've told me after the fact that they really appreciated that it tested them in a natural manner, rather than a type of competition.