Interviews that test for anything that isn't directly related to the job the candidate will be doing are essentially codified discrimination - the expectation that someone will have a skill or significant knowledge outside of the job itself is effectively a way to filter out candidates based on arbitrary criteria even if they are capable of doing the work.
In other words, Leetcode interviews favoring people with lots of spare time is by design, because that's who companies that use Leetcode want to hire. There is little reason to believe that will change.
I can stretch your logic even further that giving BE task to FE person is a discrimination because they don't have luxury to work on BE. Why do we discriminate against QA people who don't have luxury to work on dev jobs? Why do we discriminate against people who don't work as developers at all?
Imagine that you're run-of-the-mill java programmer, but you'd like to dive into Machine Learning, or BlockChain, or whatever. Some companies will require you to have 3 years of previous experience before considering you for such job. Others will give you a Leetcode interview to ensure that you're smart, and then let you learn the actual tech stack on the job.
Also, Leetcode problems might be removed from everyday development work, but most of us did learn those things at some point, i.e. in college, so asking them in the interview kind of makes sense, it's kind of "common denominator" for all programmers.
LeetCode seems to have become accepted by candidates as a way to do (1), leaving the interviewer more time for (2).
At least, that how I assume people think it works. In reality, hiring is just hard, and if you lean too hard on shortcuts like LeetCode, you come across as lazy, and you end up hiring LeetCode assholes who you catch doing LeetCode during work hours "to stay sharp". One of the most useless team members I ever worked with was good at code challenges but terrible at real work because he didn't care. He wasn't invested in working on the actual problems we faced as a company or as a team.
When we had an opening for an infrastructure engineer I created a handful of gitlab projects (terraform, puppet, python) and put some effort into building some baseline infrastructure. I allowed the candidate to choose one to work on, and then gave them a real world challenge. Not some tricksy bullshit to catch them out, just a realistic task they might encounter. They were given access to an environment where they could run the code. So at the end, I had a runnable merge request to review. Why? Because, to me, the purpose of a code challenge isn't to find the top 10%, it's to weed out the bullshitters. The rest is about figuring out what makes them tick, whether or not they're a good personality fit etc.
There will always be some sort of arbitrary selection screen as long as there are more people who want these high paying jobs than there are actual high paying jobs.
As an attorney, when you change jobs you've already passed the bar.
I personally use a dead simple 'leetcode' style program because I want to see they have the basics and can communicate them. I have had to filter more than a few people just because of that. If you can not handle some simple if's and for loops you are in for some real trouble later on. Sometimes they will come in and bust on through it quickly. Which actually helps me decide. Because I can then say 'oh you got through that semi quickly which site/book did you learn from?' That opens up what they know and gives me a good handle on how they are technically. I can then move quickly on to 'let them brag about previous work'. That shows if they were passionate for or was it just a job to grind out. Some cases it matters others not so much. If they come in and really give it a good try but struggle a bit and can say why I may recommend making them a bit more junior and pairing them with someone.
I also do not see it going away. I recently proctored some classes in my org. By the time the 'class' was done most had not bothered to even do 1 or 2 chapters. It was mostly just watching a 20-30 min video with whatever level of homework you wanted. I watched many of them for a few months after. The ones who bashed it all out were ones who tended to be tech leads and suggesting better things to happen.
1. You seem to think that your interview version of basic concept of 'simple ifs and for loops' is the base tier of programming. It's not man, everyone has their blindspots and you are selecting for candidates who are most similar to you.
2. You display hubris in your skills test by assuming that people who can brag the most are somehow more qualified than those who are more humble. Protip, people who code outside of work are not better developers. They are just enterained by their work skills in their personal time.
3. You display immense superiority claiming that your 'class' could not achieve what you wanted them to achieve. You attach meaning to this result. Not many people really want to study at work.
2. The interview is not about the code. I want to see them in action and see how personable they are (a grump/huckster will ruin a team). I usually have very little time with them so the test has to be simple (something someone who is semi competent can do in 10 mins). That they are studying outside shows they are at least willing to do the work (and a bonus and helps shortcut many things). Learning to do things is usually part of the job. I do not expect them to do it outside of work. But it shows passion if they do (which is not a bad thing but is sometimes needed to grind out more glue code). I am usually more interested in what they used to work on and can they describe what they did. I do not even really care what the thing is. I want them to explain it to me. Explaining what is going on is part of the job many times. As in 'hey so and so wants a powerpoint presentation of what you have been working on for the past 3 months'. Some are good at it many are terrible at it. I am not looking for slick presenters but people who understand what is going on and show that they can do it. Interviews are about time management too. So you have usually 40-70 mins to decide if someone is worth it. You have to divvy up that time into chunks. That is on the interviewer. I usually spend the first few mins just trying to calm the person down. Then the next few with a semi simple test and explanation. The rest of the time is them showing off and hopefully asking questions about the job (not all do). Them not interviewing me shows something too.
3. The whole class was voluntary. I could have snapped the whip and made them do it. But that was not the point of the class. It was to be a group thing where we learned from each other. It was up front that you can do this on the clock or off. It was up to them. It was very free form. I do not think it was too much to ask them to watch some training videos for a framework they were going to soon be using? My 'meaning' that I attached was many do not want to put in the work but still reap the reward. Honestly it kind of shocked me the numbers. It was not like a couple of people dropped out. It was 95% of them. All of the other people helping with these similar classes had the similar results. My 'bar' for them was to watch 1 video per week over 12 weeks (for 9 videos) and some (optional) simple code test. Is that hubris? I was not expecting much at all.
'Not many people really want to study at work' Well then that will be a problem for many. If both 'do not want to study outside of work' and 'do not want to study at work' are both true you will find your skills rusty and long term unable to do the job. I have watched it happen over and over. At some point the tech stack will change. You will need to learn it. I can honestly say I have not gone many days in my career learning something. Reading docs, reading tutorials, watching vids, classes, prototypes, whatever.
Not to dismiss your opinion, but where are the proofs?