Interesting. When reading the release notes, I didn't quite understand that point correctly.

This makes it much clearer:

TS 3.8

type T = { a: { b: { c: string } } };
declare const x: T | null;

const a = x;       // typeof === T | null
const b = x?.a;    // typeof === T['a'] | undefined;
const c = x?.a!;   // typeof === T['a']
const d = x?.a.b;  // typeof === T['b'] | undefined
const e = x?.a!.b; // typeof === T['b']
const f = x?.a.b!; // typeof === T['b']

repl

TS 3.9

type T = { a: { b: { c: string } } };
declare const x: T | null;

const a = x;       // typeof === T | null
const b = x?.a;    // typeof === T['a'] | undefined;
const c = x?.a!;   // typeof === T['a']
const d = x?.a.b;  // typeof === T['b'] | undefined
const e = x?.a!.b; // typeof === T['b'] | undefined
const f = x?.a.b!; // typeof === T['b']

repl

So if you're on TS 3.9, then it makes sense to remove the functionality that stops non-null assertions within an optional chain.

HOWEVER, the rule isn't useless. It's still completely incorrect to use a non-null assertion at the end of an optional chain x?.a.b!.
This was actually the case that the rule was intended to catch.

I think it's reasonable to add a check to allow a non-null-assertion around an optional chain if, and only if all of the following are matched:

• the TS version is 3.9
• the non-null-assertion parent is:
  • an OptionalMemberExpression with optional: false
  • an OptionalCallExpression with optional: false

That will allow x?.a!.b and x?.a!(), but it will still ban:

• x?.a!?.b and x?.a!?.()
• x?.a! and x?.a()!
• (x?.a)! and (x?.a)!()

Awesome!