Zooming out, there are two kinds of production infra software:
1. the kind that devops people directly see a need (usually a scaling need) to integrate it into a stack of existing production software; where this integration may or may not require additional development-time work (i.e. connector glue code in the business layer), but is either way an ops use-case. Examples: any caching layer, any message queue.
2. the kind that developers integrate with in order to get the semantic guarantees that particular kind of software offers; and then ops people are left "holding the bag", needing to deploy that same software (or something compatible with its wire protocol) in production because that's what the business logic was written to depend on. Examples: most databases; object storage; map-reduce workload engines.
Usually, it's pretty clear which bucket a piece of infra software falls into—either it's developers or ops people that suggest it as a solution, but rarely is a piece of software equally loved by both.
But Redis straddles the line between these usually-clear clusters of software. It can be a metrics-reactive "patch" to a running system to get it to scale better; but it can also be a development-time foundation for business logic, or a dependency of a library where it was a dev-time foundation for its business logic (e.g. any "background worker" library.)
In other words, Redis Core as a project, serves two masters: it must both be
1. a stable, scale-multiplying, worry-free daemon you can easily toss into your existing legacy infra;
2. a feature-rich "durable data-structure server", allowing developers to obviate the keeping of durable state in the app layer itself.
The new leadership certainly will care a lot about use-case 1.
I'm pretty sure, though, that the previous leadership (i.e. Antirez) cared almost exclusively about use-case 2—making developers' lives easier by taking durable-in-memory-state-management code they were writing, and replacing it with calls to Redis. That's why we didn't see TLS support and so forth for so long. Redis wasn't being built for ops people; it was being built for developers. Code that went into complex deploy-time use-cases, was only ever added by Antirez as a consequence of systems developed for Redis now depending on running it in production. (E.g. you don't scale Redis into a cluster; you develop for the sharding semantics of Redis Cluster, and so therefore you must deploy Redis Cluster. You can "upgrade to" Redis Cluster after-the-fact, but it's far harder than just writing your code to be "cluster-safe" at the start. It's idiomatically a development-time choice you're supposed to be making, knowing the eventual "scaling goal" of your system.)
Yes, the rest of the core team—mostly ops-focused engineers—gradually accrued around Antirez. That's why many of these ops-time use-cases did start getting addressed.
I'm mostly worried that now, with Antrirez out of the picture, the team is unbalanced in the other direction: there's no one on the core team pushing the "developer productivity" side of the story.
To me, that laser focus on developer productivity was what made Redis consistently the infrastructure component I would most want to integrate to solve a problem, if it offered a solution to that problem. I knew that "the Redis approach" would always involve just a library import, a connection URL instantiation, and one or two atomic Redis command calls; whereas other libraries might require me to write delegate modules, serializers, attach to special listener modes, etc. And I always knew I could just open redis-cli and prototype out those same commands against my local zero-initial-config-required Redis server; where other infra might require me to fiddle with everything from setting my own compile-time flags, to JVM memory-management, to Docker image volume mounting, etc.
I really just hope that the new leadership retains enough of the spirit Antirez has been injecting into Redis, that they'll reject PRs that solve ops use-cases but come at the expense of developer productivity (e.g. moving to entirely-async command execution, and then deprecating the text-based Redis wire protocol because it's hard to integrate its parsing into a Jepsen-correct threaded execution engine, or something like that.) Such features wouldn't hurt cloud deployments for existing Redis users at all, but they'd sure scare away new developers from finding new ways to replace business logic with Redis.