You *can* place most of your code directly into header files, but there are several disadvantages to doing so. Header files themselves are not actually compiled. The precompiler basically copies all the text from them when it as if it were part of the code file before it is passed to the compiler. (Technically, the compiler doesn't care about the extension, .h or .cpp are the same thing. You *can* compile a .h if you wish, but they're made different to maintain a good design practice and be easily understood).
For starters, header files are meant to be somewhat language independent (although, that isn't really the case). The point is, you should be able to use the header file from other languages to call your C++ written functions, and vice versa. This is only in common usage with C++ and C in practice. You will often find that C++ headers contain [extern "C" {], which means that anything in this block is actually C, and not compiled by your C++ compiler.
The header file doesn't actually need matching code either - it can represent the definitions of functions which are already compiled. A library (.lib/.a) file is the obvious example. It enables vendors to distribute usable APIs without handing over the code. (Either because they don't want to, or they do so to stop you breaking things, and of course for code re-use).
Your own code files are used in a very similar way. When compiled, they are converted to object files (.obj/.o), which aren't much different to library files. They contain the compiled instructions for what was in your code file, but not the code for the definitions that it references (because code files know nothing of each other.) It's not until all these objects and libraries are linked that they can call each other's code. What might help you to understand why things are separated is to properly understand the build process - files are compiled separately, and then linked with a linker. Here also has it's advantages - only a single linker is needed, but many compilers can be used.
On the same subject, object files do not need compiling each time you want to build your complete app. Only when a change is made in the code file does it need recompiling. Normally, you will be building your app regularly when only a few code files would have changed (to test), and object files can be reused if the code is unchanged - resulting in a much faster build. If you're placing all your code into headers and using a single code file, it will all need recompiling each time, and it will take a long time. Some applications take hours to build from scratch, and doing so for every small change is a terrible use of time. (Compilation time is such a problem that efforts are made to decrease it further, using precompiled headers).
There are also times when you won't be able to declare everything in header files alone anyway due to cyclic dependencies. This is when a header file you include in one relies on the contents of the header than includes it, such that neither can be compiled. Since you cannot define things multiple times, and both code files cannot know about each other, you need to have a code file to include one, and place a forward declaration into the header file.
On the other hand, there are times when you MUST declare your code in header files for it to function correctly - when templates are involved. Templates are compiled separately for each type they are used with, so placing them into a code file would only create the objects that are used in the same file - not the generic functionality you want. There is the "export" keyword which, in standard ISO C++, should solve this problem, but in reality, many compilers don't properly support it, and people stick to the old include method anyway.
There's more, but I've written enough.