The rule does catch the logical OR case, the issue is that the rule does not catch cases with unrelated logicals at the beginning (playground).

Why? Because it's just a really, really, really hard problem to solve using the AST.
To illustrate this, take your case like this

a || b || b.c

For a human this is really easy to parse and understand, but the AST this produces is this:

{
  type: LogicalExpression,
  operator: '||',
  left: b.c
  right: {
    type: LogicalExpression,
    operator: '||',
    left: a,
    right: b,
  }
}

It's difficult to properly associate the fact that b and b.c are positioned sequentially in the logical in the general case. Parentheses and mixed logicals further complicate this by changing the AST shape due to changing precedence.
Combined with the fact the rule needs to also understand the expressions can be of the form !expr, expr, expr != null, expr !== undefined && expr !== null, ...

It's just a hard problem to solve in the general case!

Happy to accept a PR if anyone wants to solve this in the general case!

Hey @bradzacher! Many thanks for the detailed answer!

Why? Because it's just a really, really, really hard problem to solve using the AST.

to be honest is not! and can be solved easily with flatLogicalExpression from eslint-plugin-unicorn

https://github.com/sindresorhus/eslint-plugin-unicorn/blob/df4295b53eb33f7c34b5bd81c1c3ce50192bcb65/rules/no-useless-length-check.js#L35-L41

I remember 1 year ago I wrote a rule prefer-array-includes to do the following and logical expressions are not too scary 😂

Code

1 | foo === null || foo !== 7 || ![8, 9].includes(foo)

Error 1/1

> 1 | foo === null || foo !== 7 || ![8, 9].includes(foo)
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Use \`.includes()\`, rather than repeated conditional logical OR \`||\` operators.

Output

1 | foo === null || ![7, 8, 9].includes(foo)

update:

also while checking AST Node you would use LogicalExpression selector but ❗️ it should be :not(LogicalExpression) > LogicalExpression

It's funny cos when I was writing my comment I was thinking that the entire rule could probably be refactored to do exactly that - collect the expressions to remove the AST from the equation.

Theres probably a lot of abstractions that could be built into the rule to improve it and reduce the verbosity of the code.

It's grown a lot over time. Again - happy to accept a PR!

Fixed by #6397