We've spoken about this before - errors should never ever be in the codebase, warnings should really not be, but it's not terrible if they are.

The recommended rules that are warning:

• no-unused-vars
• no-explicit-any
• no-non-null-assertion

I think no-explicit-any should probably be an error at this point of TS's maturity.
But the other two are more difficult.

Non-null assertions are a useful tool when used sparingly. We use them copiously in this codebase because TS API types aren't great, and neither are some of our types (eg .parent).

Unused variables are just a part of the development cycle, but they shouldn't exist in production code. The problem is that historically there were a number of tools that would hard-block the rebuild pipeline if they encountered ESLint errors. So by setting it to error you can end up getting in people's way and frustrating them!

I come from a perspective of lint at scale where it's impossible to enforce "lint 0" across the entire codebase, so leveraging the different severities is an important tool.
But I definitely understand that at most codebase's scale - warnings don't really have a good use beyond migration usecases.

So I'm in favour of this change.

One alternative to the assertion is just adding "unnecessary" checks to help TS refine the types.
People are really averse to adding unnecessary checks but ultimately defensively programming isn't the negative people make it out to be!

An anecdotal "case study" of sorts. Flow does not have a "non null assertion" operator. In fact there's no way to type-assert your way out of a nullish type like you can in TS because flow disallows unsound assertions.
The only way to handle it is via runtime checks.

So the entire Facebook codebase (the largest JS codebase in the world) is built with many "unnecessary" checks to help flow refine types.

To make it even worse - the graphql schemas have every field listed as nullable by default because technically any field could throw (which is silently logged and the value nulled out). In practice most of the fields won't throw though. So there's even more checks in the codebase than the average codebase.

Lots of "unnecessary" code that really doesn't harm anything or cause any measurable perf impact.