The SLAB allocator effectively has similar tunables and watermarks (number of objects in an array-cache, number of objects in l3 lists, alien caches, etc), and it performs very well in very many real world situations.
SLQB uses lists rather than arrays, so it is also more flexible to tune at runtime than SLAB. But in practice it is very difficult to adjust the sizing of these kinds of things at runtime. I've taken the dumb easy (SLAB) way out of it and periodically trim down some of the lists. That can cut back memory usage for unused slabs, and they can grow back if needed (and trim is relatively infrequent so it doesn't harm performance).
Thanks for the article, BTW. I feel like I understand the thing better myself now too :)