There are two very different kinds of simplicity in software engineering: simple interfaces and simple implementations.
Simple interfaces are absolutely critical, because the budget for interface complexity is paid out of your head.
But simple implementations are far less important. The budget for implementation complexity is paid out of an ecosystem's capital investments, which can be unbounded and can grow steadily over time.
If two implementations have the exact same features, the simpler one is better. But that is rarely the comparison we are asked to make: in practice, capability and complexity grow together.
Even systems-level programmers working in C have a highly-abstracted relationship with the hardware. By the time a modern optimizing compiler has worked its magic, the processor has applied branch prediction and pipelining, and the actual machine instructions are translated into microcode, the connection between the programmer and the real machine has become very tenuous indeed. And that is a positive thing!
fet·ish n. An object of unreasonably excessive attention or reverence.
And partly it's because a lot of teams are still new to the idea of shipping ambitious applications, and think they can still get away with user experiences of yesteryear.
The result is a culture of "many tiny libraries" that gets the tradeoff backwards: by overemphasizing the implementation simplicity of each library, there is an explosion of total interface complexity for the programmer -- once you integrate a sufficient number of tiny libraries to deliver ambitious capabilities.