> Oh come on: this is a well-known property of garbage collectors and should have been covered in an entry-level CS class.
There's plenty of BS tought in academia. In CS that would include love for modeling tools (I had classes about IBM Rational tools, bleh), OOP and other forms of sophisticated complexity. The practicioners tend to dislike GCs, but again it's not a good argument.
> a real heap allocation is really really slow
There is nothing preventing a heap allocation to be almost as fast, at the cost of memory fragmentation/overutilization and/or slower deallocation.
And that's where the whole tradeoff is. Memory allocation has to track data explicitily, GC tracks data implicitly. Typically this tradeoff is expressed in a memory over-consmpation of GC to amortize the GC deallocation slowness. And it's all dandy on paper, because the argument is "oh, just take more memory and you're fast again". Which is not such an easy thing to do. Such memory could be used as a IO caches or to run other processes. And over and over companies rewrite their memory-hogging GC-ing services into explicit-memory allocation languages and they run faster and what's more important, utilize less memory and thus make the whole system faster. They can run on much smaller VM instances etc.
So the whole "GC is as fast or even faster" is dubious in general sense, IMO. And most of the papers trying to prove it is of form "in this specific circumstances GC can run the same or even outperform mangaged memory lanagues".