Fundamentally, Go was aimed at huge code bases (think ten million lines) that live for decades. C++ code of that size takes a long time to compile (45 minutes to a few hours). If you have 30 people working on a project, and they each compile a few times a day, over 20 years that adds up to a huge amount of time.
One of the issues with C++-style includes is that they slow down compile times, because you see the same file over and over, and only process it the first time, and the rest of the time you import the text but don't do anything with it. But the compiler has to wade through all that unused text. So Go said, not just that you can only have the imports that you need, but also that you can't have cycles in the imports.
Now, from where I sit, the "no cycles" is much more clearly related to compile times than "no unused" is. But I think that they both come out of the same philosophy: "We're not going to permit less-than-optimal stuff to accumulate in the imports, because over the long run of a project, it bites you". It bites you in that, as time goes on, it becomes harder and harder to fix, and because it makes the compiles slower and slower.
Keeping code clean. If you can't compile with unused imports/variables, you can't forget them.