[gen220]

IME, this isn't so black and white.

In some situations, that engineer has a very strong mental model of the business domain they're modelling in code. It's a model forged by years of experience in the domain.

The model has complexities, but they are generally a minimal set necessary necessary to span the domain.

At first sniff, new engineers might find the code overengineered. It's a Chesterston's Fence dilemma. Except, in this circumstance, you have the builder there to explain the fence, and IMO it's wrong to assume malfeasance (obfuscating for control), when there are other contributing factors.

IME, the way to resolve this ambiguity is paired programming and communication. After the 2nd or 3rd session, the mental model should prove to be transferable or not.