Scripting languages exist to create your game logic easily, like input to character movement, when to play a sound, what sprite to show at a given moment, and other high level stuff such as that; you'd use C++ if you need to create engine logic, like physics processing, or if you needed the functionality to play a particular type of audio file, or dictating how the engine would render a sprite to the screen.
The reason for having two languages like this is that C++ is a beast, and not only do game designers/artists have a hard time taming it, but even seasoned programmers may be tired of having to wrestle with it; scripting languages make it easier to implement game logic, even though it is less efficient than C++, which is why it's recommended for use with non-critical code. The engine takes care of most of the heavy lifting already so you probably don't need to use C++ if you don't want to, but if there's something about your game that requires a lot of processing power (like random world generation as an example), you'd want to consider using C++ lest your game's performance suffer.
I see where the guy discouraging the usage of GDScript is coming from; for example, in UE4, there is also a clear distinction between using C++ and visual scripting, and they encourage you to create certain generic features via C++ which you then hook-up on a case-by-case basis via visual scripting. It makes sense since you can then use that particular code later on in another project, as the code becomes infused within the engine itself; you have your own very personal version of that engine with features specific to the games you make (or maybe you'll contribute those added features to the main engine.) Thus, scripting is reserved truly for one-off logic, and even then you can probably think up some generic solution to whatever problem you're facing which can then be applied via the editor through changing of its exposed variables. Perhaps this would be the ideal approach, except again it leaves game designers and artists too reliant on programmers to create functionality (and without a paddle if one is not present); it also leads to spending extra time ensuring a part of your code can be reused easily, when in reality you may never use that code again, or use it so sparingly that the time spent factoring and refactoring was for naught. There is another parallel: UE4 also asserts that an entire game can be created using only visual script, and they have proven that it is possible, with IIRC only a ~10% performance loss compared to pure C++. Again, this is primarily to appease non-programmers, as it makes it much easier for them to create games.
I think the inclusion of C# will be a nice compromise on that front; it's not too difficult for game designers/artists to learn (I was able to pick it up, anyway), it's reasonably convenient to create game logic in, and it comes with all the features you'd need for code maintenance and extensibility like access modifiers and namespaces.
