* Lists, sets, zsets and hashes are all means of constructing queries that act on data (or metadata) as well as key names; it's misleading to suggest that "keys are everything" in Redis.
* Sets aren't simply a way of storing things for which you don't want duplicates; they are the idiom in which flexible queries are constructed in Redis, period. redis sets : SQL joins :: register-operand instructions : C code.
* In the same vein: since probably the most important idiom in Redis is storing things indirected through keys (often incr ID keys) --- such that for instance you can index and query data through set math operations --- you might want to spend a chapter very early on explaining this idiom. It's not a weird hack to store "bob_friends=set(jack,jill,jim) bob=hash(name: bob, role: admin) &c" --- it's how you're intended to use Redis.
The very idea that one might need to store the same JSON blob in two keys so that users could be indexed both by name and ID suggests that the author hasn't really metabolized this idea. Nobody who works in Redis regularly would ever make that mistake; they'd give users an opaque incr id, and then index those ids by username in a separate key.
The idea that one might be worried about how much space those indexes consume is weird, since any other database would consume even more space to do its (much more heavyweight) indexing.
One might worry that readers new to Redis would get the impression that Redis is much more narrowly targeted than it in fact is.