Having a GC enabled OS doesn't mean the GC runs all the time or it is the only way of allocating memory.
The last generations of Oberon OS had support for video editing applications as an example.
There are real time GC applications in production being used to control weapons systems, including live targeting and soft real time factory automation systems.
Regarding D, using @nogc or -vgc allows the developer to control when the GC works, it at all. What the language lacks is a GC that can match real-time GCs used in soft real time systems.
There were GC'ed operating systems in the 80s. The point is not this. It's writing applications where you can maximize your CPU usage.
If it's a game, it means that you want to write your code so that the highest number of objects are visible on screen and are being updated on each tick. If its's a multimedia software, you want to be able to run most sounds / videos in parallel at the same time. If it's an interpreter, you want to have the highest instructions-per-second count.
etc etc... the point is not to have "good enough" performance, it never has been as soon as you use non-trivial apps. It's always "how fast can it be" / "how far can I push it", and an implicit language-level GC puts limits to this.