This is false. A header guard will prevent a .h file being included multiple times inside a .c file. It will not prevent a .h file being included in multiple .c files because each .c file is its own compilation unit (well, usually at least). It doesn't even make sense preventing a .h file being included in multiple .c files because what purpose would a .h file even have then?
These arguments hinge on the Dev being pretty careless.
This bridge doesn't need guard rails. A competent pedestrian wouldn't walk off the edge.
Transitivity.
When you include a header file, it might include other header files. There are no real restrictions on what other header files it might include, as they may be part of the implementation, rather than the interface. We see this particularly clearly in C++, where private members and member-functions must be declared in header files.
The header files included by a header file, may change across versions.
Obviously, we don't want to omit any of our #includes just because a library we use happens to include it. This wouldn't solve our problem anyway, though: different headers may overlap in the headers they include.
This means it must be safe to include a header several times (i.e. inclusion of a header file must be idempotent). Diligence isn't enough. Fortunately, it's trivial to do this with the 'header guard' pattern (#ifndef MY_HEADER_H...)