Let me first start by saying that I, too, dislike the prevailing interview process for software development jobs.
While I agreed with many of your points, I could not stop thinking what a huge time burden of implementing something like what you propose, at scale. For a growing company with several work streams and projects hungry for talent, the interview approach you posit would never work.
Another thing that came to mind is the fact that educators and cognitive scientists have been working for decades in what constitutes a good and effective test. Here you seem to claim that somehow you and your folks have "cracked" the system and have come up with a test process that's guaranteed to yield good long-term and performant workers?
Finally, I feel this approach while intended to alleviate some of the most common pain points of the interview process, it tries to reduce it to a number. While it would seem a number is plain and objective, much like a test score, it neglects to "tell the story" and unless all you want are gifted and highly skilled human automatons, you need a way to gauge "soft skills", which one would argue are as important as their core technical competency.
Actually, go look for the 'tokenadult comments on work-sample tests to learn that this approach has been known for something like half a century to outperform interviews.
This answer could possible address the test question. It leaves the other two issues I raised unanswered. Not that you have to address them, but just saying that the approach you guys implemented might work well for a very small subset of companies that share traits in terms of company size, structure and industry sector.
