This article seems pretty muddled.
First, one reason GCd languages are slow is because they GC more than necessary; not necessarily because of the GC itself. It's not always possible to statically determine what needs to be GCd. Go is pretty good at this, though, especially since pointers are explicit unlike Java. You also have cache issues here. Even if the GC tries to assuage these cache issues by smartly placing objects, this is a far cry from the speed you get from a cached stack.
Secondly, the "GC can free when it wants" is not an indictment of malloc-based heap usage. You can easily plug in an allocator that does the same thing with respect to freeing memory at an opportune moment. IIRC jemalloc does this. You can argue that jemalloc isn't malloc, but since your programming style or language doesn't need to change if you want to use jemalloc over malloc, it doesn't matter -- comparing GC to malloc isn't the real question at hand here, comparing GC to a malloc-like memory management API (or an abstraction over it) is.
Almost all the improvements that a GC has over malloc-like memory management mentioned in the article can be implemented as a policy in a jemalloc-like pluggable allocator. Smartly managing malloc() calls and delaying free() calls is orthogonal to garbage collection, it's just that garbage collectors invariably do this since it's necessary to offset the performance hit of putting everything on the heap.
The only legitimate performance feature mentioned there is that a moving GC can handle the cache smartly. It is true that malloc can't do this. However, malloc doesn't have cache problems in the first place -- managing the cache in a GC is making the best out of a sticky situation; malloc doesn't cause that situation in the first place.