It's kinda like a complement to memcached then, right? Memcached gives you an off-the-shelf distributed hashtable that you can stick things in. Redis gives you an off-the-shelf list or heap server that you can stick things in. You might eventually want more control of the algorithms that you can run on these, but if it's not yet worth setting up a separate server, you can glue these components together and get a decent approximation.
That's kinda an enterprise-y architecture choice in my experience. There's excellent reasons for it (much like Service Oriented Architecture) but I generally see folks evolve into it over time rather than starting from it, unless they come from an enterprise-y background where its assumed from the beginning. In particular, Rails and some other opinionated frameworks start from the assumption that 99%+ of the business logic is going to get executed in the web tier, and while I'll bet you that some of the more famous Rails deployments eventually move away from that, Rails would fight you every step of the way if you were trying to do it in greenfield development.
Redis makes a great complement (or drop-in replacement depending on use case) for memcached. Relatedly, I love how these (and other OSS tools) let little guys play with big boy solutions without having to have big boy budgets or organizational resources to make use of them. I think Facebook probably has about 10 terabytes more memcached than I do, but it turns out that memcached is really freaking useful way down the scaling/complexity curve, too.
I make fairly pedestrian use of Redis, generally as either a persistent cache, shared memory, or schemaless DB shared by multiple Rails processes. In-memory structures have a lot to anti-recommend them in the Rails world: at any given time I have 4 server processes and 2 worker processes running, and each of them would need a separate copy of everything. There would be consistency problems. Those processes have a lifetime measured in days in the best of cases to minutes in the worst of cases: following a restart, any in-memory structures have to be rebuilt from the underlying data source. Hypothetically assuming demand for my products explodes and I can no longer deal with only a single physical server, Redis plays very well with being accessed from multiple servers, whereas I'd have to write some sort of REST API to reimplement Redis (poorly) on top of my actual people-pay-money-for-this application code to share that state among multiple physical servers, if I were to go down that route.
Redis has been an absolute dream to administrate: the total overhead for me was "apt-get install redis-server", adding three lines of configuration to Rails and tweaking two in Redis, and doing one SCP command when I migrated servers. The RPC/command parsing overhead is, empirically, negligible in my use cases. Don't take this advice if you're Google (I know you're Google, but for the general "you" here), but many people are not Google.