It depends on what you want your tester to do. I do think it is a skill that is worth paying more money for, but I'd rather have a passionate, skilled tester than one that reads code for most positions. Having at least one tester who can read (and preferably write) code is a very handy thing.
At the one end, you have testers who can use automation tools but can't modify them, but who know what tests will find the bugs and are great at reducing bugs and communicating. Often these testers are very experienced, and can approach a testing problem and break it down quickly. I am fortunate enough to have worked with such individuals, and I learn a lot from them. However, they can only do black-box testing. While there is a lot that can be covered with black-box testing, especially with test-savvy developers who can perform test plan reviews and experienced testers who can often guess at invisible boundaries or perform skilled exploratory testing to find hidden boundaries, there are some things white box testers might be more likely to find.
On the other end, you have SDETs, who are full software developers who apply their skills to the domain of software testing. SDETs will not only test, but will usually develop test tools as well. A tester who codes can write fixtures, automated checks, test scripts and so forth, and can write well-organized, maintainable automated test code. The key downside is that such a tester is also a developer, and gets paid like one. The secondary downside is that such a tester might really want to work as a pure developer, and their testing skill set might be weak.
For the in-between level that you are mentioning, you get white-box testing. Such a tester is someone who can look at the code to identify equivalence classes and boundaries that aren't visible unless you look at the implementation of the code (or have an overly-detailed spec). You might also get debugging, depending on how comfortable the tester is in the IDE. A skilled reader of code might be able to reduce the up-front documentation burden on the developer, by using interfaces to determine the behavior of the functionality, so documentation can be written later in the cycle and testing can happen sooner. A skilled white-box tester could even participate in code reviews and find potential bugs before they are ever coded in, eliminating the extra development and test time that would have been devoted to those issues. Because this hypothetical tester can't write code, however, developers may still need to develop tools for this tester's automation.