A core conflict is determining who should hold complexity ("how much" is implied). From an operating systems perspective, I like seL4's approach of being a highly minimal kernel, which necessarily means pushing out significant complexity to userspace to handle. I want to go even further in that direction. Despite the massive complexity spike, kernel minimality has significant benefits for increasing userspace programs' power. I think programming languages are somewhat different. Both operating systems and programming languages are deeply foundational notions of abstraction, and even mesh: Smalltalk[0] or Forth being said to include an operating system isn't outrageous. An operating system exposes languages (e.g. shell commands, syscalls, libraries, services) and a programming language undergirds a system. My suspicion is that it's because an operating system is built up, whereas a programming language is the tool in hand. They're at such different levels of construction that they aren't comparable. I have a refinement, which also ties in something I sneakily avoided earlier: programming languages are like kernels, especially microkernels like seL4. Bundling the whole OS is cheating; the job is already done. But I think there's still a difference. When a kernel is built, the OS isn't far behind; a purpose is set. When a programming language is built, it's made (usually) for generality. The exceptions to this (domain-specific languages) prove my point: they have a purpose in mind. The complexity is still there, but building an operating system seems to provoke long-lasting further abstractions (services, components, libraries) whereas programming is more fragmented in its abstractions (frameworks, libraries, language features). Put another way: operating system developers seek simplicity of the whole system, since that is there scope. It's harder to define a system for programming languages, although it is there (the sum of programs produced), and so optimizations are more local at the expense of global progress.
[0] https://dl.acm.org/doi/pdf/10.1145/2525528.2525534