They tend to have well-written and well-used code, so what’s not to like? 
But it’s not seen much usage as a libc allocator, from what I can tell. There is one up-and-coming Linux distribution (“Chimera Linux”) which intends to ship with it, but they haven’t fully launched yet (and I don’t know how many users they actually have.)
Besides the fact that it hasn’t seen extensive usage as a libc allocator like the OpenBSD one has, its primary mechanism of committing/decommitting memory requires the kernel to maintain per-page protection information. This will increase the kernel’s memory usage (4 bits per page, whether the page is actually used or not) and is a performance hit for page faults (since we have to check the per-page information), fork() (since we have to re-protect pages individually rather than as a group, and we also have to allocate and copy the page protections arrays), and decommitting/unmapping (since when cutting areas we must resize/reallocate/copy the page protections arrays.) That seems like a significant disadvantage.
The performance differences on a build job were within the realm of noise (I got results of around 29.2s for the OpenBSD malloc and 29.6s for mimalloc – though the mimalloc sys time was consistently higher, it was around 12-13s vs. OpenBSD at ~10s.) On some applications like the Debugger benchmark it was faster (the benchmark ran at around 1.7s-1.8s instead of 2.3 or 3.0+s), admittedly.
One thing I didn’t check until now was relative memory usage. It appears mimalloc does use less memory than either hoard2 or OpenBSD (in terms of actual pages used, not commitments/reservations, where I expect it uses much more), and not by a small amount either, but double-digit percentages or more in many cases. Maybe it’s worth revisiting then; but at least in my testing the system crashed after not too long with this in the syslog:
0xffffffff994c8d98->VMAnonymousCache::_Commit(1073741824): Failed to reserve 1073741824 bytes of RAM
low resource memory: note -> normal
debug_server: Thread 3885 entered the debugger: Segment violation
stack trace, current PC 0x1c2f5936d3b </boot/system/non-packaged/lib/libroot.so> mi_thread_init + 0x2b:
(0x7feea61bd100) 0x1c2f58a94d2 </boot/system/non-packaged/lib/libroot.so> thread_entry + 0x12
i.e. it looks like it tried to reserve 1GB RAM on thread entry, and then crashed when it failed to do so. So it appears the commitment behavior here is still not great. If we can manage to make it behave more sanely here (and maybe avoid per-page protections at all), then perhaps it’s a contender again.