Why to use .cpp files if I can have all of my C++ code in .h file?
A few reasons:
(1) Incremental Build Times
When projects grow larger, managing the build time is problematic especially for C++ projects. Building 1 or 5 minutes after a minor change makes a big difference. This is emphasized by most changes in large projects being small and require a lot of testing. Add to that any attempt of TDD and refactoring, and you are a dead slug with sicilian shoes.
Splitting into header and body, and moving it to libs improves incremental build times tremendously.
(2) Statics
For many things you need a single instance of a type, i.e.
// .cpp
static Foo foo;
There is no way (that I'm aware of) allowing this in a header-only project. Compiler specific solutions are limited, e.g. __declspec(selectany) in MSVC is limited to POD types.
[edit] C++17 now allows inline also for variable initialization, so this is not a blocking issue anymore.
(3) Implementation hiding
.cpp / .h separation is the only way to clearly separate a public interface from implementation details. You can throw class members into a private section, but that doesn't work for other entities.
(Even the header/body separation is leaky unless you add additional techniques such as PIMPL, so this argument is a bit weak IMO, but again, in a large project I'd dearly miss this efficient if imperfect method).
Great question, anyway - you've recognized that there's something afoul with the C/C++ build model, which I consider an ancient relic of horrible implications.
You should try how far you can push a "header only" model (or, at least, a "almost only headers", to allow for statics). You might get quite far - also it would be interesting to hear from people who have tried.
It might be worth a try to use static libraries to separate and encapsulate implementations, and otherwise keep all your code in headers. I can see a few problems with that, but it's nto that our current modus operandi is trouble free.
You could put all your code into .h files. Contrary to popular belief, this won't duplicate the code across your .obj files. Modern compilers are much smarter than that.
Compilation is somewhat an issue though. If you have 20 .h files all included into main.cpp, compiling main.cpp will take a while. And it will be recompiled, including all 20 of your implementation .h files, every time one of your include files changes.
Then there's style. It just looks wrong to me. But this is a matter of preference.
Then there are references. If ClassA uses ClassB, and ClassB uses ClassA, which one do you include first?
Header files (.h) are meant to be used to define the interface so that your classes and code can be used in other translation units. If you place implementation in the .h file then you end up with multiple copies of the same code, compiled into each translation unit that includes that .h file. That defeats the point of splitting your code into small pieces that can be studied and developed in isolation.