It very much depends on the style of coding test - personally, I'm more than happy to do take-home style tests where I prepare something in a matter of a few hours, but I can't stand "leetcode" interviews or anything where I'm pressured to produce in 30 minutes or less; perhaps that's because that's typically not how I work in the real world and in my experience, they do a really poor job of demonstrating my skill set and experience.
I have terminated interviews before they even got started because of poor interview loop design from employers.
I recently failed a CS coding test. I was asked to solve a problem in 10m. I solved it in 20m and was rejected. I came up with a solution and communicate it right from the start. My solution was totally clear and readable. I just needed time to warm up and attentive to my code. I love CS. I love solving problems and reading books about Algorithm and Data Structure. I implemented them from scratch as a hobby. But the interviewer guy is not caring about that and said process is process. I felt disappointed at first but felt lucky after that since I wouldn't want to work with those people in the future.
10 mins per problem sounds extreme except for something that can be answered in no more than 5 lines of python (no code golf of course). Even then its signal-to-noise ratio (from an interviewer's perspective) can't possibly be too high. Most places would ask you to solve a moderately nontrivial problem in 30-50 minutes
From the other part of the table - we'd lose more candidates if we did take-homes. People in general prefer to study once and use that knowledge for multiple companies at once, you can't optimize take-homes like that.
I have terminated interviews before they even got started because of poor interview loop design from employers.