@JoshuaKGoldberg Could you please explain why type parameter usages in the implementation should be ignored?
Neither the issue description nor the closing PR explain this.

Is const array: [T, number] = [value, 1] somehow bad?

Type parameters in the body is type checked using the base constraint of the parameter, so : T should be equivalent to : unknown. Type parameters are not realized until the function gets called, by which time the function body has been type checked already.

...In other words, if the rule reports, then you could remove the type parameter and rewrite the function body, and achieve a function that's as sound as before.

Type parameters in the body is type checked using the base constraint of the parameter, so : T should be equivalent to : unknown.

Aren't they non-equivalent when assigning to T, acting more like never?

function f<T>() {
  const x: T = ""
//      ^
// Type 'string' is not assignable to type 'T'.
//   'T' could be instantiated with an arbitrary type which could be unrelated to 'string'.
}

In a way, they are the widest possible type when assigned from and the narrowest possible type when assigned to. I realized how tricky it is so hopefully my second paragraph is a better phrasing of what I meant.

Putting it another way:

A type parameter T bounded by extends U acts like a transparent¹ nominal type.
It is only assignable to any, unknown, T or U
It only accepts any, never or T

Note: for unbounded type parameter (eg <T>) is the same as <T extends unknown> and thus U = unknown above.