It's not true for typical use-cases, when objects aren't processed one by one, but in bulk.
> Next, you have type bloat
What's the problem? Do you pay a special tax each time you need create a new type?
> Prepare for a lot of this
That's not how it's done in C++. You typically have a template for handle types, so that PlayerHandle is just Handle<Player>.
> Handles are also a lot bigger.
The article mentions, that handles are typically smaller than pointers. A pointer is 8 bytes (on 64-bit machines), but handles can be smaller if not so many objects are needed to be created.
> Next, you have the issue of resizing your memory array.
There is only problematic to resize it down, which is almost never needed.
> dozens of arrays
> manage the lifespans and scope of all these object pools
It's not a problem. Each subsystem owns its arrays and destroys them only when the subsystem itself is destroyed.
Same for other responses. Great, you can just implement a lifespan array in every subsystem. If your sub systems are very simple (e.g. single Entity component is the only thing you're allocating in a game, maybe Resource as well), then sure, its simple. Not sure what it's buying you, since you apparently are also freeing all entities and scene elements at once too. But for a complex system where there are many types of objects (dozens or hundreds), and where lifespans are complex (some short, some long), then having "every system implement its own pool" adds a lot of complexity. Then not only would you want type-safety with a Handle<Object> for every type of object, but also some kind of affinity for the sub-system which currently manages that lifespan (unless you just have a single Pool for every object type, which re-introduces the lifespan issues).
Again, other responses I'll lump into "sounds like for simple systems it isn't substantially more difficult than pointers". I guess if it has a meaningful performance tradeoff, then it might be worth it (where a simple free list or using system malloc would be too expensive).
If you say you don't need many objects, so counters can be small, and you never need to resize the handles array, so indexes are valid, and you don't have lots of object types, and don't have lots of subsystems, and lifespans are purely scoped to subsystem lifespans, and don't mind type bloat all over your interfaces, then it sounds like handles are a perfect fit. I'm trying to imagine what's so bad about using pointers in such a simple system, and what we're "solving" (e.g. just &memory_array[next_index++]).