Concerns

What is the concern of the package.json?

No seriously, what is its point?

As far as I'm aware its purpose is to be a manifest that describes this module, and its dependencies for the compilation/linting/packaging tools used by the developer, but also for those reliant on this package.

Last time I checked, those who depend on this package couldn't care less what your specific linter settings are. If they want to lint your files, they will use their rules.

Change Management

Your specific organisation may have a lenient change management practices, but imagine explaining why this file change late in a project, say two days prior to release just before a big event that must be pulled off successfully.

Let's have the conversation around eslint: Ah yes that is a development file, that is not packaged and released. It's a nothing change.

Now about package.json: Ah yes that is the manifest that governs dependency management in the project. Oh but that is just a dev only section. Well yes it's copied into the package. But it does nothing. No it wasn't tested. No it's not going to break. No we didn't perform an integration test, we were just doing a dev orientated change. Okay, I'll back it out.

Appendices

It's hard enough to delete code when it's in its own file. You have to prove that nothing relies on it. The positive is that as a file, it is easy to see as a discrete unit.

Trying to delete a section from a file is even harder. You have to prove that no one uses that section, even if they load it. If the file is crucial to have working it will often be left behind because the effort to prove nothing breaks is too high.