Anyway, stuff in .gitignore can still be added to the index if you so wish.
Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy.
There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.
For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else.
I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use.
Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar.
Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.
I have a few team who does commit their .vscode folder, they use it to set up their environment the same way (usually when a project differs from another).