Writing ANY nontrivial software well demands not only a knowledge of software techniques, but at least some familiarity with the application area.
Also, writing almost ANY nontrivial software well demands a knowledge of the environment in which the software runs. In embedded software, especially the stuff that runs on small chips without an operating system, one may need to know details of the hardware environment and work very close to the hardware, keeping track of pin assignments, interrupts, etc. That's a challenge, but it's a different challenge than application developers of non-embedded software who have the challenge of writing extremely portable software that runs on a huge variety of platforms with varying resources and operating systems.
One of the problems discussing embedded software is that it's such a broad topic. My first exposure to it was seeing a presentation given by some guys who were writing software for the engine controllers that controlled large jet engines. Those guys had to know software development, their hardware environment, and they also had to have some understanding of how the engine itself worked. A mistake in the software could cause a plane to crash and/or damage a multimillion dollar engine, so they were encouraged to review and test their software before deploying it on an actual engine. Because their computing hardware had to operate in an extreme environment of temperature and vibration, they used rugged old slow chips that were very constrained in memory, and had just enough computing power to get the job done.
The challenges there are a bit different than the task of writing embedded software for an infrared TV remote control. And I'm not minimizing the challenges of a TV remote, trying to optimize hardware cost, make the best and most intuitive user experience, etc.
Even if you consider non-embedded software running on modern networked computers, most programmers need to know not only programming, but also something about their application area. Writing a good finite element modeling program to help mechanical engineers compute stress and strain using 3-d models of mechanical parts requires a different set of knowledge and skills than writing an efficient and fast large-scale e-commerce site, which is different from writing a good compiler, which is different from writing an engaging and popular action game for PlayStation, Xbox, and the like. And all of these are different from embedded software to run a microwave oven, or a pacemaker implanted in a person's chest, or a newspaper printing press, etc. Software isn't all the same.
Who should write embedded software? The people who know the area well.