Empty directories do not contain files or information, it's entirely reasonable for a VCS to omit such a feature. Not sure which use case for git is hindered by the inability to check-in empty directories. I would even suggest such a use-case may be a case of DIW
For instance, it is nice to think about the repo holistically sometimes before I have say an actual unit test to put in the directory, it is nice to create that structure in the repo.
We could easily get into arguments over the specific uses of committing empty directories against the difference it ends up making in terms of stability and extensibility. Instead, consider that: 1) this behavior is very surprising, and 2) it offers no advantages to users, only disadvantages to some. Hence, it is unergonomic. My complaint was precisely that for extremely popular tools (such as git), it is worthwhile in general to sacrifice ease of implementation for ease of use, because the developper effort is amortized over the number of users.
But it's not really surprising that one can't commit empty directories, one can't commit directories at all. Git is a tool for version controlling the lines and bytes of source code under version control. It's a deliberate decision to focus solely on that.
Consider that what is one person's ease of use can be another's pain in the ass. I'm thankful that git has not chosen the path of trying to cater to everyone and their esoteric use cases. I've used other tools that do and it ends up creating a mess instead. Instead it does one thing and it does it well.
I think that if you dig you'll find that if there's something git doesn't do or doesn't do well, that's because a lot of smart people have already looked at that problem and come to the conclusion you shouldn't do things that way.