Project Management is Process Management
Whether you are a traditional PM or an agile practitioner, project management is about managing process. Like any knowledge domain, the deeper your understanding of the underlying processes and procedures you're dealing with, the better you will be able to manage process flow and identify risks and impediments to your process.
With that in mind, you could theoretically manage a Mars mission with zero technical background, but having sufficient domain knowledge to understand the details within the project you're managing is more likely to lead to a successful outcome for the project.
If hire-ability is your key metric, then the only correct answer is "whatever the hiring manager needs to see on the resume to give you the job." If percentage of successful outcomes is your key metric, then you're asking the wrong question.
PMO vs. Technical Project Management
In my personal experience, a company that manages projects out of a PMO tends to favor process experience over technical experience. Most PMO-managed projects use non-technical PMs, so while they may not be indifferent to technical skills, it has never been a hard requirement for any company that I've worked for.
On the other hand, jobs that advertise for a "Technical Project Manager" or require technical leadership for a given project tend to look for process experience first, but often look for sufficient domain experience to ensure that the PM can lead the project on a technical level without having to defer all estimates to members of the team.
None of these differences are really formally defined. A good, non-technical PM won't take long to figure out whose six-week estimates for embiggening widgets are wildly off-base; it's just a process tracking issue. On the other hand, a strong technical leader may have a harder time determining why widget-embiggening takes two months to move from development to QA, because it may not be a technical issue at all.
It All Depends
Like much in life, and in project management in particular, it just depends. Technical skills are always valuable if they apply to your current problem domain, but they are not the key skills necessary for successfully shepherding processes.