Earlier quoted context omitted.
Under a different lens, that implies that previously iOS-only engineers now must also become familiar with the macOS codebase, and so more able to contribute to it. Given the large number of those engineers compared to the previous size of the macOS team, this may help more than hurt macOS (as long as you assume the engineering teams are of equivalent quality.)
While it's tolerable to have engineers jumping between projects in, say, web frontend, I'd imagine that operating system security work is incredibly sensitive to programmer context-switching - you can't dive deep into the security model of a desktop system in your 20% time when you're working with an entirely different system (with a different CPU architecture) in your 80% time. Of course there will be some specializ…
For the Darwin team which is the actual core OS they would have to deal a lot with CPU architectures. But they again they have always dealt with this since back in the NeXT days. ARM and x86 isn't a big deal to manage and there isn't much evidence that something is wrong in that area.
For the UI teams i.e. System Frameworks, Cocoa, WindowServer etc. They are abstracted away from worrying about CPU architectures and they are the ones responsible for all the bugs we are seeing today. You can argue context switching is an issue here but again we don't have much visibility that iOS/OSX engineers are jumping back and forth every day.