Depends on how you're looking at it. A commit in Git is a snapshot of the whole repository so it doesn't matter where in the tree did you run git commit.
The tricky part, however, is that "." argument in your example. git commit accepts pathnames, and if they are specified, they substantially change its behaviour: normally git commit records the new commit based on the *staged* changes: changes added to the staging area (also "the index") by means of the git add command; specifying pathnames make git commit ignore these changes completely and record
the new commit using the current (as in the work tree) state of the files passed to git commit. In your example git commit will supposedly pick all the tracked files in the current directory and use their content to create a new commit; if there are modified files in other directories in the work tree (no matter whether staged or not), they will be ignored.
So, yes, in a sense, running git commit . in a subdirectory of the work tree is like committing only the changes in that directory, but you should clearly understand that this is vastly different from Subversion where committing a subdirectory actually performs a kind of server-side merge -- such a commit will succeed if there's no changed files in that subdirectory made after our base revision. In Git, the resulting commit will be the whole state of the project, as usually.
Hence, as I've said, whether git commit . is a real use case or not depends on your preference. I, for one, do not like such shortcuts and prefer to explicitly git add what I need, even if these changes are localized to a subdirectory, review what I'm about to commit (using git diff --staged) and then commit.
