I don't think take-home projects are horrible, but I agree that when handled in the scenarios you mention, they're a pain. In past companies where I helped in the interview process and included a take-home project, I've found a few things that helped.

One thing that I noticed worked well was taking an open-ended task that allowed the candidate to work as little as possible. We'd let them know they did not have to spend more than an hour or two on it because the expectation was for us to evaluate their initial solution and in the second round of the interview they would pair with someone to talk about their work and potentially expand it.

For instance, we gave them access to a REST API and asked them to build something that pulled the data and use React to display specific info. They didn't have to style it or put all sorts of fancy bells and whistles. If they could tackle that well enough, we'd bring them in and spend about an hour pairing with someone to add something else like write unit tests, add styling or pagination, etc. We just wanted to ensure that they knew React, could talk about what they did, and how they collaborated with others. I think it served us really well.

Interviewees should also be direct if they can't or don't want to do take-home projects. In one scenario, someone said they couldn't do any take-home projects for legit reasons. We didn't reject him - instead we offered him the chance to pair directly with someone on the team as part of the interview process.

As long as expectations are clear on both sides, the take-home approach can serve well.