'eslint:recommended',
    'plugin:@typescript-eslint/eslint-recommended',
    'plugin:@typescript-eslint/recommended',
and it's not a great out-of-the-box experience. Is there a possibility to make some of this work a little bit more gracefully? Some ideas:
if a variable is never used at all, you only want to elaborate on no-unused-vars - preferring const instead of let is a noisy suggestion until we actually see some use-site.
if an ESLint rule can detect that TypeScript has noUnusedLocals enabled, then maybe there's potential for no-unused-vars to bow out and yield to TypeScript - at that point, prefer-const might be reasonable to re-enable.
At the very least, the first point seems doable to me.
Coordinating noUnusedLocals, no-unused-vars, and prefer-const
Coordinating noUnusedLocals, noUnusedParameters, no-unused-vars, and prefer-const
    Apr 7, 2020
if an ESLint rule can detect that TypeScript has noUnusedLocals enabled, then maybe there's potential for no-unused-vars to bow out and yield to TypeScript
This is doable... kind of.

Two issues with it:
If you don't have type-aware linting enabled, rules do not receive any information about the program used to parse your code. This would be fixed by feat(typescript-estree): always return parserServices #716, but it's a breaking change, and is queued up for the next major (whenever we get around to that...)
Even with feat(typescript-estree): always return parserServices #716 - we don't currently do any implicit reading of tsconfig from the workspace. Which means we'd have to build that in.
if a variable is never used at all, you only want to elaborate on no-unused-vars - preferring const instead of let is a noisy suggestion until we actually see some use-site.
We could extend prefer-const into our plugin, and add checks so that it ignores when a variable is unused, but that would be a significant departure from the base implementation, so I don't think it's something most users would expect / want.
The above work would be the only way to actually do this - lint rules are all completely isolated, so there's no way to conditionally disable a rule if another rule reports.

This is why, for the most part, rules endeavour to not step on each other's toes (doubly so for reporting contradicting errors).
prefer-const has always been a little bit contentious. Some people love it, others don't. There's arguments for turning it off entirely.
I'd love to turn no-unused-vars off completely, but it's enabled as a core recommended rule in ESLint, so we have to have it in our recommended set as well, so that users get the correct errors for TS code (uhh, well kind of correct - #1856).