I’ve thought about this a little more and discussed it with some colleagues, and I think I can articulate the tradeoffs with using directories in a use case like this a little more clearly. Ultimately, what I’ve learned isn’t really novel; it’s mostly just internalizing what’s already been covered in What's the purpose of the Directory layer? - #2 by alloc and applying it more specifically to our immediate use case. Still, I wanted to share the summary here in case it’s helpful to somebody else later.
For us, the main reason we’d want to use directories in a situation like this is for shorter key prefixes; we wouldn’t likely be making much (or really any) use of things like moving or renaming directories. Our use case would be “inboxes” for a relatively high-traffic messaging service. The idea of shorter prefixes for each message key is—on the surface, at least—appealing because we’d be inserting/reading a bazillion messages, and saving space/bandwidth on the keys seems like a win.
The problem for our use case is that the cardinality of the space is too high for us to really cache directories, and so we’d be querying the directory metadata for virtually every interaction with the message store. That’s almost certainly be creating a hotspot in the database, and so I think it doesn’t make sense for our use case.