If you read the response you'd realize that it depends on how the key is generated.
Is not a "bad design", is a feature that allows to include or exclude derived values, if you do so then the original values are used and the encoded private key would be smaller.
The reason why they'd keep the original values when the derived are available might have to do with backwards compatibility and/or legacy constraint
> With this optimization, the values of n, e and d are not required, hence are ignored by typical implementations whenever p, q, dp, dq and qinv are available*
> *at least for OpenSSH, they do not have to be present: setting p=q=1 and dp=dq=qinv=0 makes the implementation use n and d.
I misread the second quote. I suppose that is evidence, but setting them to an incorrect value suggests that this might not be a valid file even if it works.
This is a particularity of OpenSSH though and not supported by RFC 8017. The fields are mandatory and required by the spec to contained the correct values.
Is not a "bad design", is a feature that allows to include or exclude derived values, if you do so then the original values are used and the encoded private key would be smaller.
The reason why they'd keep the original values when the derived are available might have to do with backwards compatibility and/or legacy constraint