Yep. Node.js has this for instance (you have to enable it with a command line flag, but it's easy enough to do). I imagine most GC languages have a similar option.
The biggest problem with GC is that it is often global, and a simple call to invoke the global GC doesn't usually help from a local scope. There are some arena-based allocators (I believe OCaml's GC uses this strategy) where this may be more beneficial.
But the question always looms: if there is not enough memory to serve an allocation invoked from a hot loop, what should the program do?
Note also that in advanced GCs, such as .NET or the JVM, a hot loop that doesn't allocate will often not need to be stopped by the GC at all. There are even GCs (all proprietary as far as I know) that guarantee a fixed pause time, so that they can be used in real-time workloads - Azul's JVM GC has this option for example.
Rust does not ship a garbage collector with your binary, so there is nothing to pause your code.
When the compiler adds those drop() statements, they just free the respective memory at runtime. There is no need to pause your application to do that.
The garbage collector needs to pause the application because it takes time to calculate in runtime which parts of the application memory are safe to clean. If the application was running in the meantime, there's no guarantee that the blocks it marked as "safe" are actually still so.
I guess Rust and C++ also "pause the world", it's just predictable when it happens. It seems kind of arbitrary in some ways, like maybe I don't want the "world pause" at the end of this scope. There are ways around it obviously, but you start language-wrestling at that point.