For the past three years, I've spent all of my time consulting to test automation groups in a variety of organizations. My clients' test automation focuses entirely on basic happy path and boundary case tests. In that context, I would go with good programmers with little testing skill over good testers with little programming skill.
Test automation is software engineering. Automated tests are software. Like other software, the majority of the cost happens after the code is initially written. Writing software that reduces those ongoing costs is hard. It's real programming that takes just as much skill as writing applications.
My experience is this: Testers who have a little programming skill can usually write automated tests that work. Their code tends to be procedural, and filled with lots of incidental details, such as GUI terminology, test framework terminology, or literal data values.
Generally they have not developed skill in abstracting important concepts from the details, such as classes, "page objects," and other common test automation patterns.
Generally, they have not learned about how to write code that is expressive, with low coupling and high cohesion. As a result, their code poorly describes the responsibility being tested, and it's difficult to change. Given that automated tests have to change in response to changes in both requirements and implementation, and that these changes happen regularly, the difficulty of changing the tests creates a great deal of pain. Further, when the test fails, the code and the stack traces give little aid in diagnosing the failure.
I've talked with scores of people about successful and failed test automation programs. The ongoing cost of automation is one a huge contributor to test automation program failure. (Actually, the biggest factor is not the cost, but people's surprise at the cost, but that's a story for another day.) Initial cost matters. Ongoing cost matters more.
On the other hand, not all programmers are great at programming. If you want a great test automator, you'll need some reasonable way to assess programming skill.
Of course you will also need testing skill. Given the ongoing expense of test automation, you'll want to make sure the tests you automate are worth the cost. Programming skills can reduce the costs of automated tests, but you'll need testing skills to make sure the automated tests test provide value.
With a few rare and delightful exceptions, I have not been able to help testers improve their programming skills to any great degree. I have, on the other hand, been able to help programmers improve their testing skills and practices, at least for the kinds of basic tests that are the core of most test automation efforts. Perhaps some or all of the difference can be attributed to my coaching skill and style.
I want to reiterate that my experience is entirely with people automating fairly basic happy path and boundary tests. If you're doing performance testing, security testing, or some other kind of test that requires specialized skills beyond the basics, I don't know how to advise there.
And no matter what amount and type of test automation you're doing, you will also want people with excellent testing skills to do exploratory testing.