That may be true for the "what", but certainly not for the "why".
Why is best inferred from context imo, otherwise it's a smell for a system with too much scope.
You can't context-out business requirements, IMO. Also code can have bugs. You need more formal requirements definition so you can compare behavior to requirements so you can find out bugs. Otherwise, how do you find the bugs?
I can't even count how many times that I've had the DRY vs. verbosity of code conversation in trying to norm a team.
I'm in the camp of a little verbosity and repetition for the sake of clarity is worth it.