I think it really depends if and how you're going to use the Redis features. If you plan to make Redis a big part of your overall design, then maybe separating caching out into Memcache servers still makes sense.
One issue I've run into is shutdown and start up time for Redis, when you're storing large amounts of data. You risk being without a caching layer for a large period of time if you need to restart Redis, where Memcache, due to the lack of persistance is ready right away. Honestly I'm not sure it that still an issue, but I believe it is. Of cause this is only an issue if you're using Redis to store other data than just your cache, but the temptation to do so is pretty high once Redis is available to you.
You could of cause have two instances of Redis, but if you're not using the features in one of the Redis installation, then maybe you could just as easily use Memcache.
As with so much else, it's a question of your use case, how much data you have, what type of data and how you expect to be able to access it.
The bigger issue here is starting an empty (cold) caching instance and overloading backends because all the requests are MISSes and go to the backends. Persistence allows you to avoid this problem. Even if you run caching servers in some geo distributed setup, persistence will still help by reducing unnecessary geo bandwidth.
It's pretty hard to find even a single use case where in-memory caching server without persistence is better than the one with.
This article makes some claims:
https://medium.com/@Alibaba_Cloud/redis-vs-memcached-in-memo...
A relevant SO post: https://stackoverflow.com/questions/10558465/memcached-vs-re...
Personally as a dev I would start with redis and only consider swapping if I ran into a perf bottleneck I could prove was better in memcached.
One option is KeyDB which has multithreading and persistence beyond RAM capacity: https://github.com/JohnSully/KeyDB
Memcache is for caching only, it's very good at it, there is basically no administrative overhead and people (i.e. other developers) know that if you stuff data into memcache, you should be prepared to lose it.
Redis is, to me at least, much more akin to "shared data structures as a service". Sure it's also a key value store, where I could cache data, but I could do that with MySQL as well. I look to Redis when I need to have data shared between components, and sometimes a key value store happens to be the best solution, other times it may be pub/sub.