I'm in Israel this week, teaching project management. In one class, a student asked, “How technical does a PM have to be?” The inevitable answer: it depends.
A project manager needs to understand the dynamics behind the work of the project. I was teaching software (and hardware) project management today. A PM for a software project needs to understand: how people gather and rank requirements, how to ask if the design is done, how to evaluate technical risks as well as schedule risks, what it means to have a configuration management system and how to effectively use it, and the results to expect from testers. The PM needs to be able to select from the varied review activities to choose the review activities for this project. This doesn't mean a PM needs to know how to do these things in detail, but the PM needs to know how to organize the activities of the project so that all of these things happen.
In addition, the PM needs to rapidly gain an understanding of the domain, specifically problem-space and the architecture part of the solution-space. If you don't know what problem(s) you're trying to solve with the project, how can you know when the project is done? And, if you don't know the architecture, you can't understand the technical risks. You may not understand all the technical risks, but without understanding the architecture, you don't even know what questions to ask.
Note that there's nothing about reading or writing code (or tests) in here. While being a developer or tester may help someone learn the dynamics of software projects, being a good developer or tester does not imply that you will be a good PM. The functional skills are different.
Certainly, a PM can be more technical than this. I don't see how an effective PM can be less technical than this.