For a game engine, smooth performance is pretty much required. If you have to a) know that you have to worry about GC stutters (which beginners are unlikely to), and b) proactively do something about it, that seems like a major failing of a game engine. If I use a game engine, it's because I want to work on the game and avoid having to do things like manage the GC.
Besides, GC is one of those things that is classically unsuitable for real-time use cases, and games are exactly a real-time use case. So you could argue that Unity choosing a GC language was a predictably a bad decision. Again, I don't use a game engine because I want to put up with bad decisions.
All of the extra convenience and features afforded by using .NET are more than worth having to do a few simple things not to make the GC trigger at the wrong times. A game written by a beginner in any engine is going to have classes of errors that make it harder to keep using the same codebase over time. Compare the few simple suggestions (many of which like object reuse apply to C++ as well) in the article to the huge list of things not to do in C++.
Besides, GC is one of those things that is classically unsuitable for real-time use cases, and games are exactly a real-time use case. So you could argue that Unity choosing a GC language was a predictably a bad decision. Again, I don't use a game engine because I want to put up with bad decisions.