The problem with GC for a game engine is not just plain performance... but it's when you're trying to bind engine objects to the scripting language. From the sc

The problem with GC for a game engine is not just plain performance... but it's when you're trying to bind engine objects to the scripting language. From the scripting side you're dealing with GC-like semantics (where object deletion can be deferred indefinitely), but the C++-engine side objects need to adhere to C++ object semantics (whether that be manual / RAII / reference counting). This gap between the two can lead to some "interesting" engine decisions: for example in Unity they have a separate UnityEngine.Object base type separate from the C# runtime System.Object type, which have very different semantics and thus lead to some funny headaches! Note that Godot's scripting language (GDScript) doesn't use GC and instead just uses reference counting implemented in plain C++, and thus were able to unify the object behavior between C++ and the scripting layer. An alternative approach for supporting GC in your game engine, would be to extend C++ on the engine-side to support GC with some black magic (aka Unreal's approach with UObject). But that requires adding an additional hacky transpiler / reflection system on top of C++... which I think has been mostly a net negative in terms of usability (if you've tried using Unreal you'll quickly get what I mean...)