Also, it adds inconsistency in JS/TS, as this rule is only enabled in TS

I do not agree with the others but this one is IMHO important.
(meaning I personally consider shadowing variables always bad, in the currently visible scope should only be one possibility for a given name)

in the currently visible scope should only be one possibility for a given name

There is only one — the variable in the current scope.

With this rule:

1 - Default names cannot be used in a nested context even if they are unused

element.on('ready', (event, param1) => {
  const button = findButton()
  
  // We cannot call unused position param "event" with a "defailt" name
  button.once('click', (event, param2) => {
    log(param1, param2)
  })

  // Unnecessary complex name
  button.once('click', (_, param2) => {
    log(param1, param2)
  })
  
  // Unnecessary complex name
  button.once('click', (clickEvent, param2) => {
    log(param1, param2)
  })
})

2 - Code validity depends on context

const version = process.argv.version

// This function was fine when declared in another module
// but if we move it here, it requires variable rename
function validateVersion(version) {
  return isValid(version)
}

// Unnecessary complex name
function validateVersion(versionToChech) {
  return isValid(versionToChech)
}

Or it requires more significant code changes.

I don't think a small risk of variable mismatch (that is not covered by testing/TS) worth it here.

Both example I exactly consider bad code 😆

const version = process.argv.version

// This function was fine when declared in another module
// but if we move it here, it requires variable rename
function validateVersion(version) {
  // long body

  // whats that version? I recall I declared this on module level - but no its the param ;)
  return isValid(version)
}

In this example I consider naming unused (but required) names _ good code style and not complex names, because it makes clear that is not used anywhere in the code:

  // Unnecessary complex name
  button.once('click', (_, param2) => {
    log(param1, param2)
  })

Maybe just personal taste.

In this example I consider naming unused (but required) names _ good code style

Except that it cannot be _, because _ is also shadowing. It needs to be _ and __, and then ___ if you have more nesting/unused position params.

// whats that version? I recall I declared this on module level - but no its the param ;)

Disabling no-shadow doesn't mean do-shadow :)

If you have actually large/complex code and the variable isn't defined as a function param (you don't see it when you scroll) — you can rename it. Here you, as a developer, can decide — this is bad code, and you want to make it clean.

But forced no-shadow means - to avoid a developer's decision, we force to change simple places.

Except that it cannot be _, because _ is also shadowing. It needs to be _ and __, and then ___ if you have more nesting/unused position params.

That's right^^
Probably I would exclude _ from that rule^^

But forced no-shadow means - to avoid a developer's decision, we force to change simple places.

No it should not be there in the first place, existing code is always the problem but also the thing we can improve.

But in short: fine with this changes as we never enforced it for JS.
If we like we can discuss adding this as a code quality improvement for both, but thats independent from this fix :)