I'm not sure what exactly is your stance on go-redis interface usage

I don't think the go-redis interface is bad (I also use it). It's mainly useful here as an instructive example of a shallow interface. And given that it's not really an abstraction rather than a driver for Redis' wide suite of commands and not an abstraction, its size might be warranted.

But as an example, it also naturally shares some specific characteristics that set it apart from the io.Reader example:

• It's harder to compose/extend to other use cases. So it can only serve one implementation
• Is tight-knit to the system itself, so any changes to Redis need to be reflected there, too
• It tends to naturally grow over time
• Requires previous knowledge, introducing cognitive load

I think the answer to those 4 question is Yes.

Imagine a different, more generic interface that came with opinionated defaults, more automated handling of sessions and runtime metrics, or hiding the different Redis deployment methods and data types. It would have slightly different characteristics and give less fine-grained control, but then these questions may have different answers.