This article makes a huge assumption: that performance is the only factor you're hiring for, and therefore unstructured interviews are worthless. That would make sense if you're interviewing for a factory of emotionless robots. But humans are social beings, and human performance as a team is more complicated than a sum of individual productivity. You need to take into account the affect that the hire would have on the entire team. Just about everyone has an anecdote about a coworker sometime during their career that was super productive, but completely demoralizing to the team. This is a very valid reason to give unstructured interviews, and if you ask smart people who give them, this is what they're looking for.
I totally agree with the utility of work-sample tests. There is nothing better to see someone's performance than simply giving them a small but relevant chunk of work to do. It is very important to keep them short and flexible though.
If you make them too lengthy, you'll skew the results against people who have better things to do with their time. What kind of person works for free anyway? Certainly not the caliber of people I want to work with.
And if you make the test too specific to certain technologies, you skew the test against smart engineers who are less familiar with that tech. If you want a problem solver, give them a problem in plain words, and let their solution be open-ended.
I don't agree with making tests particularly hard, though. Make it nuanced, yes, but of normal difficulty for a given assignment. You need the appropriate people to do the job. If you only hire top-tier algorithmic experts for your basic CRUD app, then you're going to have a very expensive CRUD app with a bored and demoralized team. If someone does sloppy work, you can spot this on a normal exercise as much as you can on an unreasonably difficult one.