docs: `no-unreadable-new-expression` rationale

Look here: ```ts function isConsentValid(consentData: CookieConsentData): boolean { const consentTime = new Date(consentData.consentDate).getTime(); const now = Date.now(); const sixtyDaysInMilliseconds = 60 * 24 * 60 * 60 * 1000; return now - consentTime < sixtyDaysInMilliseconds; } ``` [`no-unreadable-new-expression`](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/v66.0.0/docs/rules/no-unreadable-new-expression.md) wants me to do: ```ts function isConsentValid(consentData: CookieConsentData): boolean { const consentTime = new Date(consentData.consentDate); const consentTimeMilliseconds = consentTime.getTime(); const now = Date.now(); const sixtyDaysInMilliseconds = 60 * 24 * 60 * 60 * 1000; return now - consentTimeMilliseconds < sixtyDaysInMilliseconds; } ``` I would strongly argue the first is more readable. A short survey here shows that. The rule itself says: > This rule allows identifier constructors and static member constructors. Split the constructor call and member access into separate statements, or assign a complex constructor expression to a clear name before using `new`. But there is no rationale as to why. Why is it more clear? I'd argue reading the "before" above is more clean. Easier to scan. Easier to read. One less line for something simple and immediately shown that we call just one call of `getTime()` on it. I suppose I could do `consentTime .getTime()` at the last line instead to make it better still. But to me it is more clear to have the const assigned immediately to the value I want to use. At least if it is only used one. I could see this rule making sense with a default if there is at least two or more chained member accesses. But not just one. But honestly even that is debatable. I suppose my main gripe is this: If this rule has to stay as-is, please add some rationale to the docs as to why it is like it is, if possible.