.gitkeep is intuitive and easy to understand. Unignoring a .gitignore is not intuitive. This falls squarely into "clever optimization tricks that obscure intent and readability". Don't do things like this.
It's not that hard to update a .gitignore file every now and then.
Using the actual tools built in to git directly removes steps in the process, which is always a good thing, it's documented as part of the git documentation, so you don't have to create a wiki page explaining why there is a ".gitkeep" file that git doesn't recognize itself.
Saying "It's not that hard..." is fine for projects with a few contributors but does not scale.
If someone doesn't know what .gitkeep is they should be able to derive from the name that it's some special file intended for git.
If they then google it they will immediately find out what it's for.
Yes, git itself has no concept of it but it's common enough that there's plenty documentation on the internet.
Yes, because relying on google-fu is the way to ensure your build environment is consistent. /s
.gitkeep is explicitly not intended for git, because git doesn't recognize it at all.
Having the .gitignore, which is actually recognized by the git tools, means you can rely on the .gitignore functionality, including ensuring that things other than the .gitignore cannot be added to the repo.
It's not that hard to update a .gitignore file every now and then.