What do you like best?
Redis fits a sweet spot which is "out of band data store server". I work with a lot of CQRS/ES systems and in these systems it pays to have a persistent "out of process" view of typical data types such as hashes, lists, sets, etc.
It's fast, convenient, and the defaults make it a pleasure to use. Seeing how antirez maintains it makes it one of the go-to pieces of software that I instinctively trust based on years and years of astounding stability.
What do you dislike?
Redis has some sharp edges which only become apparent when you start to get off the beaten track. I recently suffered a few grey hairs because the algorithmic complexity of LRANGE is (S+N), where as the comment to insert into a LIST is O(1). The performance of LRANGE becomes problematic when taking the last few dozen items from the end of a very, very long list. Of course having huge lists is an anti-pattern, and it was easily solved by using the bindings Lua to implement a "fake" command which partitioned things into small lists, whilst taking care of pagination, etc.
Recommendations to others considering the product
Beware that Redis expects you to store data in the way you expect to *query* it. Take the time when designing your schema to imagine *how you want the data to look when you get it out*, and take care to store it that way.
In RDBMS you can query very flexibly to pull things out in any way you care to imagine, but you pay a penalty on inserts for this flexibility.
What business problems are you solving with the product? What benefits have you realized?
In our CQRS/ES system, the core concept is to pick the *ideal* store for reading, and writing. To embrace the asymmetry inherent in building systems to enjoy the freedom to pick the perfect data store for writing, reading, querying, etc depending on the exact use-case.
Redis' O(1) insert performance is idea. From there we have async processes that build idealised read-stores for certain types of data. Profiles are stored as JSON (on disk) ready to be delivered via our API with minimal involvement from the application servers. Things like contact lists, friendship groups and other "indexes" are also stored in redis as sets, hashes or lists. Redis solves all our data storage needs barring "static files" (for that we have a filesystem) and our "search" for which our clients usually expect something like ElasticSearch.