While it's ONE of the nice principles to remember; however, it's not the golden rule. Often times it's a matter of tradeoff. The complexity upfront can be for the simplification later down the road. E.g. defining a DSL would be an extra complexity upfront but simplifies and streamlines work down the road. A good developer knows how the make the judgement call to balance the tradeoff in complexity.
That's not what I'd call a tradeoff. Problem complexity isn't the same thing as incidental complexity. If a DSL is useful for the problem domain, it's not "extra complexity", it's a simple (albeit hard to implement, simple != easy) and elegant solution.
A DSL is an additional functionality adding more components to the system and thus increases its complexity. A DSL incurs extra learning cost that new developers coming onboard need to spend more effort in learning.
You can have a simple library or util module with the standard function API instead of building a DSL. They work just as well in many designs.
