Do you want to hire programmers who can't program?
I'm going to venture that you do not.
Hiring programmers who can't actually solve problems and write code is a good way to ruin a tech company. And you're not going to be effective at weeding out the programmers who can't actually program (and there are a lot of those out there) if your hiring process doesn't include some sort of programming test.
Are you willing to lower your standards because everyone's trying to hire programmers?
Maybe you are, but I don't think you should be. As has been noted in the comments and answers, there are candidates out there who aren't going to bother doing programming exercises as part of an interview process because they just don't need to in order to get a job.
But are those really the people you want to hire anyways? The ones who follow the path of least resistance, do whatever is most beneficial to them in the short term, and don't really care enough about your company to complete a simple programming exercise? Those don't seem like positive attributes, and they don't provide much confidence in terms of being able to retain those candidates long-term (which is also important for a tech company, as learning curves tend to be steep and the cost of replacing existing staff is very high).
So let those other businesses have the programmers who can't even be bothered. You don't want to hire them anyways. Unlike them, you have a plan. One that's not based on the "a programmer is a programmer" fallacy. Your focus should be on quality and sustainability, not bodycount.
Is scaring off candidates a problem?
Generally no, as long as they're being scared off for a good reason. You don't want to hire people who aren't up to scratch. And some of the people who say they "can't be bothered" due to high demand might actually be using that as an excuse to cover up a "not really that good at programming so would need all week to complete a 1 hour exercise" situation.
It's good to scare away those candidates. You want to hire the capable, motivated candidates. As long as you're not scaring those ones away too, you're good.
Every candidate you don't scare off is one you have to try and evaluate. And that can be hard to do if you're not giving your technical candidates any technical exercises to use for evaluation.
How can I improve our hiring process?
Check the content of your programming exercise. Is it reasonable and appropriate for an interviewing context?
You don't want something that's going to take days (or even hours) to complete. What you want is something simple to weed out the people who just can't program, ideally with enough room for nuance that the people who can program really well can differentiate themselves. Keep in mind what you're trying to accomplish (weeding out unskilled and non-serious candidates), and ensure your content is tailored to that goal. Don't go overboard.
If you've already got some technical staff, you can use them to sanity-check (and/or help design) your exercise.
And also consider how you administer the exercise. If you just give them some documentation and say "here, do this over the next week and e-mail it to me", that's probably only going to be minimally effective.
Better might be if you can run the exercise through a web portal, which candidates can check in and start the exercise, and once they start a timer starts counting down from 1 hour. Then they either submit something within that hour, or not. That's less open-ended, better retains the candidate's focus, and provides a clear deadline/timebox both so that 1) you're not left waiting around all week for a result that's never going to come, and 2) unqualified candidates don't throw away a week of their time trying to complete your programming exercise. They get 1 hour, they either solve the problem or they do not, and you know the outcome immediately.
And even better would be to bring them in for an onsite interview. Introduce them to a member of your development team. Shut them in a room together with a workstation. Have your developer start with some general/soft interview questions, and then they can pair-program with the candidate to solve the programming exercise. This will tell you not just whether or not the candidate can code, but also how well they work with your team. Your developer should also be able to glean a lot of additional information that you just won't get by looking at a bunch of code that a candidate wrote and then e-mailed to you.
No, you don't want to get rid of your programming exercise. But you may want to review it for appropriate content, make sure it doesn't take too long to solve, and also look at how you're fitting it into your overarching interview process.
A self-directed take-home exercise probably isn't the best approach. But the solution to that isn't to scrap the exercise entirely. Not unless you're okay with hiring crap programmers, at any rate.
Better to scare away a lot of bad candidates and a handful of good than to open up the floodgates and hire a few bad ones.