I'm specifically thinking about when to use these different types of IDs in APIs, API routes, and in your database. Assume that we could enforce uniqueness for human-readable IDs on a global or tenant basis.
UUIDs require much less storage/memory than string keys, and you can create offline bulk inserts quickly and easily with them.
Make your table with UUIDs as the primary keys, and then create a unique, human-readable lookup key as an additional column.
This gives you the best of both worlds.
It seems somewhat nice to have resources that users create and interact with via an API + CLI to use identifiers that people can type out and remember instead of copying.
Unguessability isn't a big deal because all of these IDs can be namespaced under the organization ID and the auth check can just return a 404 instead of a 401/403 if the person doesn't have access.
I'm somewhat inclined to say if we're uniquely identifying resources with a unique, human-readable string, that's the ID you should always use to refer to things. It seems slightly more complicated to explain to users that there are these two ways to refer to things.
There's also the issue (or benefit) of keeping the UUID the same if you are able to change the human-readable ID.
And don't even get me started on auth checks and someone spoofing the system because something still accepts the old identifier long after the original owner gave it up and some malicious party grabs it.