Depends on what you call an algorithm, of course. As GP mentioned bare minimum coding skills, I assume he uses really simple ones. This can, of course be relative, but maybe he was intentional with the analogy.
Because you can't really code without writing algorithms. Yes, you are never write a quick sort or implement a red-black tree, but you do have to understand problems and provide some kind of solution to them and then translate that into code. I.e. come up with an algorithm.
I used to use two simple problems, both involved math. One of them is a bit harder and the ideal solution assumes that you do remember high school math (not very complicated but something that you may have forgotten or at least something that you won't think should be used there). But it's nice, because you can come up with more and more optimal solutions and the naive one (which is O(n^2), IIRC, really just shows that you managed to understand the problem). I don't use that one anymore though. I almost exclusively just use the one that I thought was embarrassingly simple and which I used to use as a "warm up" exercise. Not more complicated than the fizz-buzz (which I hadn't heard of at the time I picked this one).
I'm not telling you here what it is, but it indeed does weed out people who can't really think through a simple problem and then can't think of a solution that consists of several steps following each other. (I.e. an algorithm.)
Now I'm not interviewing 'top' developers, just your average web devs most of the time. Another thing I'm doing in the past few years is code review. I have 2-3 pieces of badly written code that I have reviewed and/or rewritten.
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.
Because you can't really code without writing algorithms. Yes, you are never write a quick sort or implement a red-black tree, but you do have to understand problems and provide some kind of solution to them and then translate that into code. I.e. come up with an algorithm.
I used to use two simple problems, both involved math. One of them is a bit harder and the ideal solution assumes that you do remember high school math (not very complicated but something that you may have forgotten or at least something that you won't think should be used there). But it's nice, because you can come up with more and more optimal solutions and the naive one (which is O(n^2), IIRC, really just shows that you managed to understand the problem). I don't use that one anymore though. I almost exclusively just use the one that I thought was embarrassingly simple and which I used to use as a "warm up" exercise. Not more complicated than the fizz-buzz (which I hadn't heard of at the time I picked this one).
I'm not telling you here what it is, but it indeed does weed out people who can't really think through a simple problem and then can't think of a solution that consists of several steps following each other. (I.e. an algorithm.)
Now I'm not interviewing 'top' developers, just your average web devs most of the time. Another thing I'm doing in the past few years is code review. I have 2-3 pieces of badly written code that I have reviewed and/or rewritten.