In the C++ Google Style Guide's section on headers, the first line says:
Use standard order for readability and to avoid hidden dependencies: Related header, C library, C++ library, other libraries' .h, your project's .h.
But that appears backwards to me because project's headers are likely to be dependent on system headers whereas system headers are obviously not likely to be dependent on project headers. Simplifying the example given in the guide, we get the following #include lines for X.cpp that is dependent on X.h, the standard header <vector> and another file in the project's codebase, A.h:
#include "X.h"
#include <vector>
#include "other/module/A.h"
If A.h is dependent on <vector>, the style's order hides the problem. If the headers were included in the order of most related to least related the problem would be exposed.
What am I missing? Perhaps the counter-argument is that this problem would be exposed when A.cpp gets compiled but that argument doesn't stand if there is no A.cpp to start with (i.e. A.h is header-only).
It seems like quite some years have passed without an answer.
I noticed that I was in fact using the header include order dictated by Google Style Guide, without much reasoning behind it, as indeed none was given in the Names and Order of Includes section, unlike other sections. So from their goals I can only guess that was done for consistency, allowing for some automation as they said, as well as "Just pick one [rule] and stop worrying about it" so that people can stop arguing over rules.
Too bad, as it looks like the order and reasoning given by Nathan's answer in this question make much more sense today. Personally, I'd gradually switch to that style of includes.
Hopefully, the future improvements in managing dependencies in C++ code will make this situation better. Ideally, not having to worry about order you state dependencies in, at all, and having better time at detecting and removing obsolete includes, usings, imports etc.