I'm not sure I understand what makes it different from uuidv4 or base32 encoding some random bytes.

This seems to be well respected, so I'm pretty sure the issue is just my own lack of understanding?.

UUIDs collide in large apps? How? With quintillions of records? Due to implementation error? I've never heard of it being frequent except with implementation bugs.

Generating good random numbers fast is basically solved and built into all modern OSes, they already mic multiple sources of entropy together and pass them through crypto algorithms.

Even if you need multi threading, you can always just seed a thread local RNG using a seed from the OS RNG.

It seems like a lot of the novel content here is the randomness generation, and the primary value is you've packed a good CSPRNG with some entropy gathering stuff in a small size for when you don't trust the OS?

My bias is towards buy over build, so I'd be inclined to trust OS and environment provided functions over this, but I could see the value if you expect to run on some old crappy systems without any kind of decent entropy APIs.

If your IDs are not time sortable, you will waste a bunch of time looking through lists trying to find records in your db.

At the very least, these things should have time sortable options for dev use.