They're all useful if you want to have consistent settings across your team.
.classpath
and .project
mean everyone can get up and running with a project just by importing it. Any changes to the libraries and source files included in the project will be picked up by everyone when they're checked in.
The .settings
directory has things like code formatting options and what the compiler considers as warnings, errors, or OK. For consistency, I've started checking these in as well (as long as everyone on your team can agree to a standard for formatting, I guess).
I've found that the biggest limitation in sharing things across version control in Eclipse is in the library definitions. Library definitions seem to be only stored on a per-user basis, so if you reference a "library" in the .classpath file, every other user has to manually define the contents of that library (or manually import your exported library definitions file).
Edit: (Addressing @mliebelt's comment below)
You'd only commit .settings files if you're trying to keep consistency/standardisation between developers. If that isn't an issue for the project, then not committing .settings files is one less thing to worry about maintaining. Files that are specific to an individual's favourite plugin(s) probably don't need to be committed either (although I don't think it would hurt if they were, would probably be ignored?).
The two most common ones I've found worth committing are org.eclipse.jdt.core.prefs
and org.eclipse.jdt.ui.prefs
, which are core to any (Java) Eclipse project.