I'm a living example of not being a technical expert, instead being a team expert. I have worked across a broad swath of high tech for twenty years and also applied my project skills to very non-technical endeavors.
I've heard the arguments for domain knowledge:
"How will you know if the estimate is false?" - If I can't look at my team and know someone is bluffing, then I'm not serving the team. My job is to know the team and help them. More importantly, my job is to trust the team. Give them trust and be amazed what they give back.
"You need to know what the technology is to understand the project." - I need to know what the value is. I need to know how it will impact the customer and the stakeholders. I need to trust the team that they know the technology. My job is to help the team.
"You can't step into something you've never done before and lead a project." - I had zero manufacturing experience and my knowledge of HDDs was mostly at the level of "unscrew it and put a new one in." I took over all program management for a consumer products HDD group and was fully integrated within three months. I didn't focus on the technology. I focused on the team. That team saw their projects go for four per quarter to thirty, with no new headcount.
"We're a start up, we need to focus" - This only carries so far. If you're engineers are spending half their time on non-coding, then that's a lot of wasted resource. If you have a ten person dev team and need more resources, hiring one more dev will be of limited value (law of diminishing return, time to bring them up to speed on the specifcs of the tech, etc.) You hire someone devoted to all the project aspects (a chief of operations if you will) and you remove most of the non-dev work, then I believe you will get a lot more productivity out of the team.
Caveat 1: The portability of project management (team facilitation, scrum master, etc) does have limits. Crossing a major domain gap (software to bridge building) is not a one to one transfer and in some instances may not be possible. Some domains have very specific requirements, typically related to safety or government regulation.
Caveat 2: You can't be a complete domain virgin. This is similar to Caveat 1, but more talks to your adaptability. I am not a technical expert, I've never coded, likely never will. That is not to say I'm lost in the high tech world. I've worked in customer support, product marketing, product management and project management. I've worked in consumer electronics, enterprise software, consumer software, virtualization, etc. What I am really good at, is learning just enough to understand and trust the team.