This is arguable and really depends on a lot of factors. I personally take it as far as possible because it is easier to add includes later than it is to try and clean them up after they have been in use for a while. Saying that though, I also try to match my namespace/classes to obvious include paths. For instance, if I forward reference IMesh a lot then I need to use it in an implementation somewhere, what would the include path be? For my usual method of working: "acl/gfx/IMesh.hpp" would be the path and file name following the pattern I use. I started using this pattern fairly strictly after a couple SDK's began using it and I saw how nice and clean it kept things in most cases. Yes, you end up with a lot more includes in the cpp's themselves, but the headers remain significantly cleaner and more understandable in the long run. As long as the headers are easy to simply "know" what to include, there is no real hassle, if it is hunt and peck, that's bad news.
Of course, others disagree and I won't argue. My only comment is in significant code bases, I have seen no need to use precompiled headers in many cases as they didn't gain much speed when the includes are kept as clean as possible.