일단 저의 뇌피셜인데요. 확인차 읽어주세염...
.
.
.
곰곰히 생각해 보니, .h에서 include를 하지 않는 이유는 '무한 include` 때문이다

 ide의 성능이 부실하던 백악기 시절에는 플머 한 명 한 명의 실수나 오류를 찾기가 쉽지 않았을 것이고,
 그렇기에, 오류를 찾기보다 '오류를 무마'시키는 것에 초점을 둔 것.

 A객체와 B객체가 A.h, B.h, A.cpp, B.cpp로 분할된 파일(.h, .cpp)에 선언과 정의로 나누어서 코드를 친다고 가정하면,
 
 A씨는 A.h에서는 B.h를 include 하지 않고 A.cpp에서 B.h를 include 했다 치자. 
 근데 B씨는 B.h에서는 A.h를 include 했고 B.cpp에서는 A.h를 include 하지 않았다고 가정하자.

 이 경우 컴파일러가 해석할 때 B class 보다 A class를 먼저 컴파일 스퀏트를 조진다고 가정하면,

 A.h에선 class B;의 class 전방 선언을 읽은 다음, A.cpp를 스쿼트 하려고 할 것임.
 그때, A.cpp파일 어느 라인에 있는, #include "B.h" 를 보고.

 컴파일러 : 아(c++발) A.cpp를 읽으려면 사전 지식이 필요하구나!

 하며, B.h를 읽으려고 할 것이다.

 근데 Class B를 설계한 사람이 B.h에 A.h를 포함시켰으니까. 
 컴파일러는 B.h를 읽는 중에 A.h로 다시 갈 것이고.(컴파일러 똥개 훈련)

 A.h에는 B.h를 include 하지 않았으니, 정말 정말 정-------말! 다행스럽게도! 무한 include에 빠지지 않고, 

 B.h -> B.cpp -> A.cpp -> 던전 탈출.

 순으로 컴파일러는 잘 빠져나갈 수 있었을 것이다.

 즉, cpp에 include 함으로 컴파일 속도 저하를 막는 건 어쩌다 걸린 논리적인 이득 요소이고.
 (목숨을 거는 실행과 런타임 성능과는 관련은 없다고 생각해서.) 
 이렇게 IDE에서 지원하는 '파일 분할 관리' 기법과 플머끼리의 암묵적 프로토콜을 이용해. 오류를 무마시킨다!
 .. 가 사실은 빅브라더의 '신생 플머 양산하기 프로잭트'의 아주 깊고 더러운 딥 다크 블랙 부두 슈퍼 매직 뒷면이었던 것이자, 프로메테우스의 불이었던 거임. 

.
.
.
.
 ... 이라는 코린이의 망상을 찌끄렸습니다..
 제 추론이 맞나요?  

- dc official App