Good generational GC doesn't need to deallocate objects one by one, instead of that it can deallocate objects in bulk (if there is no finalizers). It can allocate memory faster because it doesn't need to use memory allocator to create every object, it just increment pointer that points to the beginning of the free space. It's true that modern GC has greater throughput than simple allocation/deallocation schemes. Problem is predictability (as been mentioned).

It doesn't have to deallocate dead objects. That is sort of the point of most collectors.

All GCs have to deallocate objects. It may be very cheap to do so, for example when you have a semispace collector and no finalizers, but switching the spaces is still a form of deallocation. Production-quality GCs don't use semispace for everything because of the huge memory use overhead, and all practical GC'd languages I know of need finalizers in some form.

Finalizers are certainly the exception rather than the rule for objects. Deallocation to me represents some action taken for a particular object and scales with the number of objects deallocated. Semi-space copying collectors do not have this property. I think we only disagree on the semantics of "deallocation" — which is why I specified my argument in terms of how things scale. Similarly compacting collectors like Java's CMS also have this scaling property without semi-spaces.

But it has to scan/mark all the objects, not just the the unused ones. This has large overhead in big-mem apps. Not to mention that usually this forces the whole app into RAM (makes swap useless) and also potentialy drains cpu caches. And to amortize this it often has more memory overhead (up to 2x) than typical fragmentation in a manually managed app.