The quote would probably be more accurate as:
> "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."
It's one thing to shift complexity to a different group/team, such as managing microservice infrastructure and orchestration that can specialize in that aspect of many applications/systems. It's very different to create those abstractions and separations when the same people will be doing the work on both sides, as this adds cognitive overhead to the existing team(s). Especially if you aren't in a scenario where your application performance overhead is in eminent danger of suffering as a whole.
Often a developer will see something big or complex and see it as a problem.
But they should consider whether this matches the size/scope of the problem being solved
In professional software development projects, specially legacy projects, often times the complexity is not justified by the problem. There is always technical debt piling up, and eventually it starts getting in the way.
Often times means not always -- what would you say some projects are doing right so that their complexity is justified by the problem?
That is the more precise adaptation of Kelsers Law.
Obviously you can always add also superfluous complexity :)