Let me argue in favor of coding problems. Unpaid coding problems have a couple of very appealing properties:
1) They are available to all applicants (not all applicants have github profiles, or can show previous work samples, or are available for short term contracting work).
2) They do not cause problems with typical IP agreements or extra curricular work restrictions.
3) They can be standardized so all candidates receive the same process.
4) They are a closer proxy to the "real work" of development jobs than many other alternatives (and there is lots of research that indicates this leads to better results).
Those properties are very important and cannot be found in hardly any other style of hiring filter. For this reason, its my belief that coding problems are central to a good hiring pipeline. I believe this so much that I'm willing to replace nearly every other part of the hiring pipeline with just the programming challenge (though that is a hard sell with management often).
The problem with coding problems is that it is very hard to come up with good ones. They should take less than 4 hours to solve (everyone severely underestimates how long their challenges are), they should be indicative of the kind of work you will you do, and they should be, if not fun, engaging. So normally when I encounter bad programming problems I chalk it up to that instead of malice.
It is everyones decision to not do programming challenges of course, and I completely understand people who will not do them. But to me the standardized hiring pipeline is the most important part and I'm willing to lose a few good candidates to get it. For this reason, I view a programming challenge as a good sign for a potential employer, and the lack of one to be a serious red flag.
If someone is using a coding challenge to get free work, that is at the least unethical and likely against the law depending on your jurisdiction.