When doing preprocessor directive #include <iostream>, what happens is similar to text inclusion (like a copy and paste) into the main.cpp, and you can compile with g++ main.cpp. You don't compile iostream.cpp.
But what about user defined files? #include "userfile.h" should do a similar text inclusion into main.cpp. Then why do I have to compile both files (g++ main.cpp userfile.cpp) if main contains all the necessary code anyways?
There isn't really anything different between "system libraries" like iostream and user-provided libraries except that the compiler will (as a convenience) leave some things implicit when dealing with the system libraries. In this case, it implicitly links to its default standard library implementation.
To expand on that, let's look at your first invocation of g++:
g++ main.cpp
Since g++'s default standard library implementation is called libstdc++, you could imagine that this is shorthand for:
g++ -lstdc++ main.cpp
(There may actually be more trickery involved, so I make no guarantees this expanded command will work as-is.)
And just in case you're not familiar with linking yet...
When you compile a .cpp, the compiler produces an object file (often ending in .o). When you have multiple .cpp files, each one is compiled to a separate object file. Then they have to be merged somehow to produce the final executable. This merging is called linking and is done by a linker. The linker's job is basically to match names in different object files and output an executable file.
Except, that's too much of a simplification. The final result does not need to be an executable, it can also be a library. (I'll stick with static libraries for now, because I think it's simpler) A library is a file name according to this pattern: lib*.a. Libraries cannot be executed. Instead, a library is just a convenient way to package up a bunch of functionality from many .cpp into a form that is easy to consume later. You can link a library with your own object files to produce an executable with functionality from the library as well as your own code.
In the example of libstdc++, if we assume your system has a static library for it, that would be a file called libstdc++.a. When linking, we strip the leading lib and trailing .a (because all libraries will have this) and just write stdc++. This is why we would pass -lstdc++ to g++.
The one problem (if I can call it that) with libraries is that they don't mean anything to the compiler, only to the linker. In order to use a library, your source code needs to #include the corresponding header file so that the compiler can see the definitions/declarations in it.
First, compilation speed, which is the tedious part of compiled languages like C and C++. You don't need to recompile (a slow process) myclass.cpp, if you don't touch it. You just recompile main.cpp if that's where your modifications are. Don't think in a two file program... think about larger programs. (The codebase where I work is roughly on 100K lines -that is small because it's an embedded system- and a full compile takes 5-8 minutes; you can't wait that for every minor change).
Also, it makes it more modular, which means you get to compile the file just once, even when used by two different programs. If you have a client-server that send over a network a MyClass object, both need myclass.cpp (myclass.o compiled).
You can also "hide" some details (specially in C, where you don't have private specifier, or in C++ using PIMPL language), because those details are hidden in the cpp file.
Also, in a very large project, I don't know if the compiler can manage such a number of elements (think that it has to have tables with all the names and identifiers).
Given the case, why don't you just put everything in main.cpp?
Note that this approach is used by SQLite to provide it's "Amalgamation" compile, which combines all of it's files into a single file for compile and that makes it a bit shorter, as the compiler is more aware of things that would rather get hidden.
