For example, constructor signature for mixins requires `any` type that conflicts with `no-explicit-any` rule. In another case, `object` cannot be replaced with `Record<string, unknown>` when used with conditional types to mean "any non-primitive value".
If you're somebody who wants to make their ts as close to provable as possible, but also be able to handle dynamic / generative content, then you run into issues of this nature all the time with (for example) linter settings that think they know typescript better than you do, but fail to recognize that there is literally no other way to express some type-concept in typescript without using a larger feature set.
However, the argument can be made against any tool, and I'd say Deno here is the least deserving: in most cases it has just adopted the "defaults" set by tsc, eslint, or prettier, and just like them it allows ignoring these rules where necessary.
That said, I also think Deno made the right choice by enforcing these by default. Hopefully, it will fight the tide of low-quality code that plagues NPM. I do have to wrestle the linter, but it's mostly because I'm writing libraries that by themselves are pushing the limits of the TS type system, e.g. in structurae[1] I make an extensive use of mixins extending built-in objects, and mixin support is still nascent in TS. This is far less common in day-to-day production code, where, for example, using `any` or `object` is more often a sign of sloppy thinking rather than a necessity.
