I think the problem with your thinking, and something that I've been trying to figure out as I sit on/direct more interviews myself, is that this doesn't actually tell you that the candidate can't code, but just that they couldn't code in that setting with that problem in the way you chose to frame it for the interview.
Meaning, I often sit with candidates who come in with 3-5 years experience in industry who can't do a relatively simple programming task. That can either mean that we consistently are drawing applicants who have been pulling the wool over the eyes of their past employers for 1/2 a decade, but actually can't program.
Or, it could mean that they get incredibly nervous coding in front of strangers, aren't used to doing more abstract problems, and once they realized this, experiencing a "snow ball effect" of nerves, wherein they train wreck in the interview.
Sure, in theory it can mean that some of them are just super nervous. But, of course I do help them if I see that they don't get anywhere. I don't think that there are too many people who will just 100% shut down without showing any sign of actual nervousness.
I didn't mention how much these guys were working at other places, but it's completely possible that they were doing a job where they could just get along somehow. E.g. the last guy who wasn't able to get anywhere with my puzzle was a candidate from an agency for one of my clients. I think he was some junior guy, but I don't know for how long he has been earning money as a developer. Obviously, the agency wanted to sell him.
Besides not being able to solve the coding problem, which I told him was not a big issue (so that I don't make him more nervous) he didn't find any issues in the sample code in the code review task. (And it has about 10 issues in 15 lines.) So yeah, some of these people may have been just copy&paste programming, they may have been tinkering with larger existing projects here and there (I don't know, maybe customizing CMS-es) or are complete beginners who haven't faced with the fact that they can't (yet) write code.
After all, you have to prove somehow that you can write code if you want an employer to hire you and pay you for writing code. Sure, it could be a take home challenge too. Some companies do that. Once I interviewed for a company where I didn't want to work for a role I was not interested in (embedded C++ developer), just out of curiosity and because they were pushing it. They had a quiz about C++ (like what is a constructor, what does this piece of code print and why, etc.) which they said I aced. Then they gave me a laptop with VisualStudio and a simple task (something like writing a text wrapping algorithm in an hour). Now not having any recent C++ experience (other than on Symbian, which used a completely different std lib) and having never used VisualStudio, I wasn't able to finish. But they have a more complex take home task. That could work for nervous types. It was an interesting experience, but I believe being able to communicate about the task is much more important than being able to type out the code on your own without any help. Well, at least for most organizations.
Meaning, I often sit with candidates who come in with 3-5 years experience in industry who can't do a relatively simple programming task. That can either mean that we consistently are drawing applicants who have been pulling the wool over the eyes of their past employers for 1/2 a decade, but actually can't program. Or, it could mean that they get incredibly nervous coding in front of strangers, aren't used to doing more abstract problems, and once they realized this, experiencing a "snow ball effect" of nerves, wherein they train wreck in the interview.