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
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.