This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their situation.

Every time I've requested changes to a pull request because the reviewee didn't know the difference between .gitignore and .config/git/ignore, the reviewee appreciated learning about the feature. The person you're replying to also clearly said their reviewees are pleasantly surprised, so it hardly seems like a waste of time. Also consider that it takes almost no effort on our part to point out this feature, no effort for them to learn it because we tell them directly, and it happens at most once per new contributor or hire.

I’d really only like my projects to talk about things relevant to the project, instead of having to think about the fact that you might be using Qt Creator.

Fair, but it depends how uniform the culture is around a particular project. Is it haskell and everyone is using emacs? Sure, include those. But trying to chase the requirements of half a dozen different editors is silly.