Depends on the age of the field. When fields are young, nobody has any domain knowledge anyway, because the "domain" just got started. At this point, things like technical knowledge, familiar programming languages, and common data protocols are crucial, because that's all the knowledge that exists.
As a field ages and accumulates best practices and social patterns, domain knowledge becomes relatively more important and technology choices become relatively less important.
Many of the biggest profit opportunities in a field come from owning the platform it's built upon, which is why it's logical to try and attract developers early with technologies they're familiar with. Eventually domain knowledge will matter more - but that depends upon the platform becoming big enough that it's a domain.
Domain knowledge of the type relevant to programmers in many fields is gained through experience programming in that field, not non-programming experience in that field.
Unfamiliar programming language is an impediment, for many, to that learning process. If the tradeoff for that is a much clearer mapping to the domain than a more familiar alternative, the unfamiliar language may be, pedagogically, a net win, but -- especially for self-study -- people are more likely to learn enough to look deeply into the domain (including through unfamiliar languages) if the initial entry path is easy from where they currently are.
The problem in this particular case is that the concerns of embedded systems are orthogonal to what anyone who knows _only_ JavaScript has ever dealt with. Those worlds are simply too far apart.
Your case is entirely valid when, say, a person is hired to work in a retail system and who had previously worked in some form of a decision support system.
