I'm going to be charitable in interpreting your answer, but, if I'm being honest, I find your tone very dismissive... (I would even say, reminiscent of StackOverflow, and not in a good way.)
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.
Oh, I definitely understand the mindset behind the decision, I just feel it's worthwhile to relax that kind of razor-sharp focus when millions of people are using your tool. Since you seem knowledgable about git, would you mind telling me how complicated implemented directories would be? (out of sheer curiosity, it's not like I care all that much about directories in git lol)
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.