This is an extremely interesting subject. I understand the "hate" for leet code, or simply live coding exercises in general, though so far the majority of "hate" I've heard for this comes from the candidates who haven't had to do a ton of hiring. Or they've had the ability to hire slower and take their time evaluating fewer people over a longer period of time without a ton of inbound pressure. Or they've set some arbitrary bar for inbounds that many people also disagree with (such as only talking to people from top ranked CS schools, or only candidates from well known companies, basically some other metric they can use for themselves as some abstraction on competence).

I do believe having someone do paid work / pair with the team for a few days is likely the most valuable, and I do actually think the best people are ok with this because they use it as a way to evaluate a company. But this strategy simply isn't scalable and can take a lot of company man hours without extremely good up front vetting.

I've found coding exercises, of some sort, they don't have to be leet-code-esque, to be one of the very few "put your money where your mouth is" activities to perform. The amount of folks that can speak forever and in-depth about what they've worked on, and then will completely fail at writing for-loops in their favorite language has astonished me. I don't believe live coding exercises have to be adversarial, I believe candidates should be offered a more accessible often if it's too high pressure for them, but I don't believe coding exercises are inherently bad or evil. I do believe there are bad or evil exercises that can be chosen.

A practical coding exercise that requires no more than 8-10 lines of code done live has generally served well in my experience for assessing candidates. I've seen similar pure failure rates from practical exercises as I have from "perform a dfs" style exercises, in the above 60% range.