Yes, it's cool and all that it's "blazing-fast". And for brand-new projects with small teams, it's probably totally sufficient. But IMO it's one of the biggest roadblocks to Deno being used for Serious Business.
Having robust linting/styles rules is crucial for robust development teams. All the established companies for whom I've worked spent years honing their ESlint rules. But most of these rules have no Deno equivalent. You can only replace ESlint with Deno Lint in fairly simple use-cases, and can't really use ESlint on Deno projects (despite my best efforts).
Even though Deno is great, even though the code "works", the inability to granularly enforce styles across a development team is a deal-breaker. Honestly the fact that the Deno team kind-of reinvented a wheel unnecessarily with Deno Lint feels like NIH (Not Invented Here) Syndrome, which is super disappointing given the respect I have for Ryan Dahl and the rest of the team.
It's not an NIH, but was done for technical reasons. Deno internally uses swc for transpiling and formatting TypeScript code. Right now Deno has 3 parsers—TypeScript's, SWC's, and v8's. So including eslint would mean having to support yet another parser, which introduces a larger binary size, extra work making that understand things, and dealing with more things that can go wrong with yet another parser. It would also mean we'd have to lint in a v8 isolate instead of just doing everything in Rust as we can do with swc.
We would like to spend making deno code easily analyzable by other tools, but a lot of Deno's infrastructure is written in Rust. It either requires extracting out the resolution code and making it usable via WebAssembly or rewriting a lot of this logic in pure JS. Either way, it's a lot of work that will take time. For example, I'd like to analyze deno projects with ts-morph. For eslint, we might consider embedding eslint directly after their rewrite.