I find long sequences of standard includes annoying:
#include <vector>
#include <string>
#include <sstream>
#include <iostream>
Considering these header files change only very rarely, is there a reason why I should not make a "std.h" file #including all std headers and just use that everywhere?
Including unnecessary header files will increase compile times.
You might like to add these to your project's standard, precompiled header file: if your project has a standard, precompiled header file, and if your files aren't supposed to be reusuable in other projects which might have a different standard header file.
This would also increase the size of your object files, which probably isn't a big deal these days.
Edited per comments that the binary would not actually be larger
It reduces your code readability (oddly enough :)). By including them all in one header file, you can no longer tell just by looking at the top of a file what translation units are including iostreams (and therefore doing IO), fstream (and doing file access) etc.
I'd suggest using an IDE that allows folding of include statements, like eclipse, and have it automatically fold the includes. That removes them from your view while still making the dependencies clear.
I hate to create a new answer for this, but I basically want to put both Brian Ensink and ChrisW's answer together:
First off, as Brian mentioned, your compile times will skyrocket as it's including tonnes of files every time it compiles. Luckily it looks like it's standard includes, so they shouldn't be changing all that often, but it'll still suck.
You can mitigate this by buildnig a precompiled header that'll only be re-compiled when you do a full rebuild, toast the PCH file, or change something included in it - but that's why PCH files normally only have system wide includes, or things that don't change that often.