"add + commit" is not a bad design at all. It is just design choice, and it also about "patch control system", that allows more logical commit history and more precise control over VCS. It allows to code all things you want and place into commit only part of your changes. You even can stage part of file - if, for example, you done two logically different changes without commit between them. May be, good analogy will be reading file with one command versus "open-read-close" sequence - simplicity versus good control.
This feature allows very comfortable, free coding style - you write what you want ad understand now, and later you can divide your changes to logically related sets. You do not controlled by limits imposed by VCS - "work on one feature, commit, work on another". Instead VCS works in your style and rhythm. Usually you don't want run "commit -a". Instead when you run "git status" you see several files that you do not want to commit right now. So you use "add + commit" sequence, may be - several times to commit different changesets as distinct entities with distinct comments. I think it's very good point of view - to track not file versions, patchsets that represent something meaningful - new features, bugfixes etc, and have VCS follow your practices and rhythm - and have understandable version tree at the end.
