If your service is hosted on a single machine, chances are that in-memory caching will have a better performance and will be easier to implement.
On the other hand, there are three situations where local caching is not enough:
As soon as your service starts to be hosted on multiple servers, which is the case for most services hosted in production, you may need to implement either centralized¹ or distributed² caching in order for your services to share the same cache.
In this case, if your language/framework/infrastructure doesn't already have the feature (such as AppFabric in Microsoft community), Redis appears an excellent alternative.
Note that in the same way, you may have a system installed on a single machine, but written in multiple programming languages. If different parts of the system need to access the same cache entities, you may either create the caching service yourself, or do it the easy way and let Redis do the job.
Redis has much more features than ordinary cache systems. Have you seen the list of Redis commands? Instead, most caching systems are limited to three actions: add, get, remove, and to expiration options. For instance, what about DECRBY? Most caching libraries I've used don't even have the ability to increment/decrement values, which makes them a poor choice for counters, for example.
If you need those additional features, Redis is obviously a solution to your needs.
In large scale environments, system administrators may need to be able to properly configure the caching servers (as well as properly chose the hardware for the particular needs of caching). Having a common caching service such as Redis means that those system administrators may learn it well and focus on its configuration, given that it can then be used from services written in any programming language.
¹ In centralized caching, all clients access the same caching service (which, internally, can use failover as well) which handles all the data and its invalidation.
² In distributed caching, each client stores cached entities. When an entity is changed or removed, the action should be dispatched to all the nodes to ensure consistency.