I don't want to let myself off the hook too easily here, because we don't hire for typical developer roles; our work-sample tests are very well defined (they're exercises in finding and exploiting vulnerabilities) but I'm generally interested in the technique overall. So let's stipulate I'm a hiring for a standard dev role. I think you make some great points.
(1) Yes, ambiguity is death. It's bad for the reason you say it is (it psyches you out, and discovering how people perform when they're at their most psyched-out is a pointless exercise). But it's also bad because open-ended tests are hard to grade and compare. Work-sample tests need to be standardized and they need to be defined rigorously enough that you can draw comparisons between candidates, and then draw comparisons between the performance of hires and the tests.
(2) Yes, grading superficial issues is also bad, for the same reason: when you give someone "points for style" (or demerits), you lose the ability to make apples-apples comparisons with candidates over time.
(3) I flat out disagree that take-home work is disrespectful of candidates. Most interview processes demand that employees submit to several (3+) hour+ long phone screens, then show up at an office for 1-2 days of interviewing. Allowing candidates to do the most important technical portion of the interview on their own time, on their own schedule, in their own location is simply better for the candidate than forcing them into a room with a whiteboard.
(4) Yes, not giving feedback to candidates is one of the great sins of tech hiring. Some of this is folkloric; for instance, there's a belief that providing feedback to candidates you opt not to hire sets you up for frivolous complaints down the road. But there are ways around that problem.