They can see the policy working...

We have linting set up in our codebase, I had to switch and focus on one half of our project, and I nearly lost my mind when I came back to the other side and realized that every time someone said they were 'addressing linting issues', that actually meant they were putting eslint-disable everywhere until the pipeline stopped complaining.
- Code reviews?
  
  "It passed CI, LGTM"
  
  The developer I report to was in charge of that side of the code base and doing all the code reviews for it .... I thought he had a handle on it :/
- I might get physical in that sitiation. And I'm very tame.

Hot take: Clean up your darn imports. Otherwise you just make the links between modules confusing and messy.
- Sounds like a perfectly normal take.
  
  Really, OP might have had the hot one with "unnecessary imports sitting around is fine".

The duality of Programmer Humor: You get posts complaining about bloat, and posts complaining about this.
- Competent people vs incompetent people.
  
  Also, slightly less competent ppl vs slightly more competent ppl.

Except those imports were used by a huge section of code you temporarily commented out, and now you'll need to manually select a dozen imports to get it working again when you come back to it.
(Sure you could have just commented out the unused imports, but the linter auto-sorted them and you're feeling too lazy to copy-paste a dozen scattered lines)
- That is what version control is for.
  
  This. Commenting out code is bad practice
- Use a good IDE, and readding the imports is pretty easy.
  I find commented code to be a bit of a smell on its own, just delete it, and if you really need it again, dig it out of source control.
  
  Yeah. My last job, a PR with commented out code typically wouldn't get approved. Either leave it in version history, or stick it on a branch
- Hum... Ignore linter advice for code that you temporarily mangled.
  It's not like you have to act upon it as soon as a blue line appears under your code.
  
  Depending on the configuration, a linter may cause the compilation or a CI pipeline to fail.
- Honestly I'll disable linting across entire files during these kinds of refactors because it's annoying having build output littered with unused imports and format warnings while I'm still working on a solution. Requires some extra diligence to re-enable and clean up before pushing though.
  
  Use pre-commit with a linter config that checks all files, local dev can have a different config to disable as needed.
- During code review, we reject PR’s with commented out code. Problem solved.

The Trade Federation greatly appreciates useful imports.

Case 1:
Just typed the ending '>' for the include and see the annotation come up.
Case 2:
Did not include the header, so not getting the code completion recommendation, making me have to type the function/class/whatever name.
Case 3:
The code completion comes up with an option of including the header (except that it is including the wrong header, despite me having already included the correct one)