Three good reasons
According to Michael Bolton from www.developsense.com.
There is a common claim, especially in the Agile community, that suggests all testers should be able to write programs. Most people who use computer programs are not computer programmers, and there are many ways in which a tester can question and investigate a product without programming.
Yet there are at least three very good reasons why it might be a good idea for a tester to learn to program.
Tooling. Computer programs extend our capacity to sense what’s happening, to make decisions, and to perform actions. There are many wonderful packaged tools, in dozens of categories, available to us testers. Every tool offers some level of control through a variety of affordances. Some provide restrictive controls, like text fields or drop-down lists or check boxes. Other tools provide macros so that we can string together sequences of actions. Some tools come with full-blown scripting languages that provide the capacity for the tester to sense, decide, and act through the tool in very flexible and specific ways. There are also, of course, general-purpose programming and scripting languages in their own right. When we can use programming concepts and programming languages, we have a more powerful and adaptable tool set for our investigations.
Insight. When we learn to program, we develop understanding about the elements and construction of programs and the computers on which they run. We learn how data is represented inside the computer, and how bits can be interpreted and misinterpreted. We learn about flow control, decision points, looping, and branching, and how mistakes can be made. We might even be able to read the source code of the programs that we’re testing, which can be valuable in review, troubleshooting, or debugging. Even if we never see our programs’ source code, when we learn about how programs work, we gain insight into how they might not work.
Humility. When you program a computer to perform some task, it will reflect any imprecision in your instructions and your underlying ideas. When we learn to program, we get insight not only into how a program works, but also into how difficult programming can be. This should trigger respect for programmers, but it should also trigger something else: empathy. 
Software Testers Need Technical Skills
According to Allister Scott from watirmelon.com.
You’re testing software day in and day out, so it makes sense to have an idea about the internals of how that software works. That requires a deep technical understanding of the application. The better your understanding of the application is, the better the bugs you raise will be. If you can understand what a stack trace is and why it’s happening, the more effective you’ll be in communicating what has happened and why.
As you’re testing, you can easily dive into the database and run some SQL queries to make sure things actually did what they were meant to, or discover and test an exposed web-service using different combinations as it’ll be quicker and provides the same results.
Gone are the days where you’d be emailed a link to a test environment somewhere that you’ll use to conduct some manual testing and provide some feedback. More often then not, you’ll start by setting up your own integrated development environment on your own machine so that you can pull changes as they’re committed by programmers and find issues sooner.
You’ll also probably be asked to build a test environment that other people can use, and a continuous deployment pipeline to automatically update that environment when appropriate.
Without technical skills you’re going to struggle with this, as it’s not just a matter of testing’ the functionality of the application, but testing the entire system: that it can be built, deployed, internationalized, scaled etc. 
According to Fiona Charles from quality-intelligence.blogspot.com.
As coding advocates keep saying, you don’t have to be able to turn out production-level code. But it’s enormously helpful for a tester to understand how a system is constructed from the inside out. When you’ve tried to write working code, you learn to know the kinds of mistakes it’s easy to make with a given language and that helps you find bugs in other people’s code. And when you can read code, you can often spot the place where the error occurred and see what else might be wrong around it.
When you can code, you can write routines to build data in bulk, and also to inject data. You can write routines that help you test (or check) faster, or make it possible for you to test a larger number of input variations than you could practically manage otherwise. You can write and run your own batch jobs. You can query a database directly, to find out what’s really getting written to it. (SQL is code, too.) You can make clever use of spreadsheets to boost your test capabilities. 
Test Automation is Development
According to Markus Gartner from www.associationforsoftwaretesting.org.
If you have dealt with some programming languages, and became more and more familiar with the underlying concepts, you might have started with some automation of your tests. Since test automation is software development, you probably need to dive deeper.
In order to apply design patterns in your automation code, you should make yourself familiar with the concepts of object-oriented classes, interfaces, and functions. Design patterns will teach you how to tailor your classes so that you can reuse commonly used code more easily. For example, I remember that we applied the Strategy pattern quite often. With that pattern, you have several strategies how you can accomplish a particular task in your working code. These strategies can then be plugged into your test automation code on demand, and be unit tested in separation of the whole application. You start to build an automation code base that allows you to plug-in different behavior thereby leading to easier reuse of concepts.
One piece of caution: learning how to apply design patterns constructively takes some time. Also, you need to teach your colleagues on these patterns, since they provide some sort of indirection and abstraction that people working with the code need to get used to. In the long run, getting more familiar with these patterns though will serve you well if you can create a shared understanding of the underlying structure.
No matter what, only applying design patterns is not enough. Over time code bases tempt to rot. They need constant care. This care comes with refactoring. Refactoring means you need to restructure your code without changing the outside behavior of the code. With refactoring you can transform an existing code base from one structure to another one. Thereby you can change your code from one design pattern to another. 
According to the guys at CodeRus.
The top programming languages
The top 10 mentioned programming languages (including both required and nice-to-haves):
- SQL or relational database skills
- Java, including J2EE and EJBs
- Shell Scripting
- .NET including VB.NET and ASP.NET but not C#
This data makes it pretty clear to me that at a minimum, professional testers need to know SQL.
In addition, there were three categories of technical skills that aren’t really programming languages but that came up so often that they’re worth calling out:
- General Web Development skills including HTTP/HTTPS, HTML, CSS, and XPATH
- Web Services or referenced SOAP and XSL/XSLT 
The top test automation technologies
- Selenium, including SeleniumRC
- XUnit frameworks such as JUnit, NUnit, TestNG, etc.
- Visual Studio/TFS
- Watir or Watin
- Fitnesse