Don't partial commits run the big risk of commiting code that may not work, since the partial commit on your own computer will be tested against your working tree, wheras after it's committed it run with a different view of the files?

It could. OTOH, most workflows I've seen use the approach "do whatever you wish in your repo and in your branches, but merging requires that the tests pass on a CI server, which only has access to the repository and has exactly zero uncommited files.

In other words, go ahead and break your builds six ways from Sunday, but they won't get merged until they pass based solely on the state of the repo.

Not if you know what you're doing. For example, say you added a bunch of TODOs and FIXMEs you noticed in existing code while working on something. Now, you're ready to commit. The TODOs and FIXMEs don't necessarily correlate to the code changes you made. Should they all be committed with the code?

Using the index to stage and commit hunks separately lets you easily add and commit the unrelated TODO and FIXME comments separately from the code. A tool like Magit makes it trivially easy to do.

And since they're comments, they have no effect on tests or the code.

In reality I use it to do partial stashes more often than partial commits.

That said, you could extend your argument such that you should always commit every touched file but that would be awful.

Just to play devil's advocate, to achieve this always-working guarantee you could: stage, commit, stash your working directory, test your code, and then unstash.

Most of the time I'm doing partial commits it's because of squashing them into older commits via rebasing. Rebasing allows you to run an arbitrary command (e.g. your test suite) after each step and will pause the rebase if it returns non-zero.