• Pretty much set/get operations on key/value, just like memcached, but with rich data structures, like Lists, Sets, Sorted Sets, Hashes, Blocking Queues. And rich commands to use all of them. That avoids serializing a bunch of data into Memcached values.
• Durability options: Redis can be used just in memory, like memcached, or can be tuned to be durable (flushing data every so often is an option, or appending data to a log file that can be replayed if the node restarts, among others).
• Master-slave: it can be configured as master slave, being the slaves your "read replicas".
• Cluster: just like Memcached, it can be sharded using consistent hashing, but that's taking care of on the client side - which can a problem if used against cloud instances that are more likely to fail (so one needs to be prepared for updating the instance list on the client in case of failures).
• Security: pretty much non-existent, or at least not built in, like Memcached. You need to resort to other security mechanisms (to be honest, Memcached had some SASL support, but I don't know the current state of that).
• Not to mention the API, which "[..] is not simply easy to use, but a joy."
• LUA support on the server side
• Good client library support, as well. One good example is the library for a Bloom Filter on top of Redis.
• Publish/Subscribe support: very cool publish/subscribe support on specific channels, pattern matching for both channel and message subscription, etc.

• LRU: one of the questions I've seen is related to the lack of LRU support, but this has been added to Redis
• Performance: I did not find more recent numbers, but some numbers from 2010 show Redis being outperformed by Memcached. That could be a good reason not to use it.

I wonder if Redis performance has improved lately and if any other reason not to use Redis comes up - please comment if you know other reasons to avoid Redis.