To be honest, I was really happy with TSLint. The amount of configuration and scaffolding around ESLint is a big turnoff from me compared to how easy it was to get TSLint going.
A lot of the most common TSLint "boxed" configurations have direct ESLint relatives at this point. For one opinionated example there is eslint-config-standard-with-typescript [1]. Using a prepared config like that is just as easy as using one built for TSLint. (It's an "extends" field that does most of the work.)
Though I admit I've kind of moved more towards even more opinionated Prettier than ESLint lately.
The larger the pool of engineers on a project (or the larger a team size) the more important consistent formatting becomes. It may not be relevant for individual projects (though I'd disagree with that as well), but it makes maintenance of projects under larger teams, including distributed teams, a heck of a lot easier.
To us, the biggest value is auto-refactoring the code to comply w/ styleguides and rules. There are many great rules in eslint that cover most known anti-patterns. For a start, just grab the .eslintrc.json from the microsoft/typescript repo.
We've hooked up "eslint --fix" and "prettier --write" to "npm run fix".
One command before committing and you comply with all our coding rules. Easy, peasy. We tie the combined checks into "npm run check", and run this in CI/CD, so we know only compliant code is merge. Check!
Most other lang tools _won't_ do this. Take PMD or Checkstyle for Java. They'll just fail your build, but won't make your code compliant.
Finally, if you decide you want to add a new code convention to your repos, it's just a one liner: "npm run fix". It doesn't get much easier.
Linting is not the same as typechecking. Take a look at the default available rules [1]. For example number == NaN is valid Javascript, but 99.9% of the time an error. Or you might want to require always using === over ==.
Generally, linting is things that are valid in the language, but still better to do otherwise.
import order, empty function bodies, leading underscores in different scenarios (if you have such conventions), sort object keys (not just alphabetically, but by use, eg. shorthands last { name: 'Jim', surname }...)
There is some overlap and it's not as crucial to have a good linter as it used to be.