From what I understood, the trick is that, for a block which was returned by free() and later returned by calloc(), the former behavior was to zero within the calloc(), while the new behavior would be to zero within the free(). If there's a bug which writes to the memory after the free() but before the calloc(), the former behavior would mean it's still zeroed, but the new behavior would mean it ends up overwritten with something which isn't all-zeros.

I'm not sure I see it as "taking advantage of"; if code is engaging in the UB of writing to invalid pointers, there could still have a race condition where calloc() appears to be returning non-zeroed memory, simply because the invalid pointer write happened after the clear. This just moves the clear back in time.

calloc(3) isn't the only way to allocate memory, nor the most common one in ObjC apps.

Actually, ObjC objects are allocated with calloc() so it might be the most common one.

It also has a better interface than malloc() because it can check for overflow evaluating `size*count`, though it'd be even better if C had first-class types and you could pass that in.