Interesting. Makes sense for open source. In the workplace for those using common IDEs things like .vscode or .idea can definitely help with consistency or shared project setup. Each has docs which mention which files should or shouldn't be committed. Personally, I just use gitignore.io to generate the file based on my company's tooling and call it good enough.
That's what I've always seen done with git or Perforce. The initial set of all likely IDE-related files is known (just talk to the people you work with...), so you just add all of them to the ignore list (of whatever kind) and off you go. Then over time, additional entries might get added, as new platforms become supported and/or new team members join who use other IDEs. And the easiest thing is to add them to the list, because if one person is using this or that tool then there's a fair chance that somebody else will be using it in future too.
One way of thinking about this is to note that there are an awful lot of these tools, and so each person should look after their own shit rather than fucking it up for everybody else. Another is to note that the number of these tools is finite, and team members won't be using all of them, and so over time the centralized ignore file will tend towards a useful degree of completeness.
