It is a CD solution, there's no CI involved at all. However, it extends the 'delivery' portion of that phrase to also include so called "day 2" Kubernetes-centric functionality such as "how does my Secret content get populated?" and "how to I apply only certain values.yaml to certain Helm release versions?" Then, Mission Manager also gets into the game of "how do I ensure my cloud resources are present alongside the software?"
It also gets into the compliance side of things (arguably it's all about compliance) in that new releases, config changes, vulnerability mitigation, downtime windows, and a ton of other stuff are optionally gated by a review process. If you want to change the values.yaml for an existing release, you can choose whether that is a 4-eyes change
That latter bit also speaks to your question about "who is the target audience for this?" because, like many things Palantir, it's a lot of the defense industry and intelligence community, as they care a lot about having gates and controls in place. Apollo specifically also gets into "edge deployments," such as what software is running on a laptop that goes out into the field, comes back to base, and only then gets its updates pushed to it
I detest them with all my heart, but I'll be straight that Apollo does actually model the deployment concerns of software very well. Every place that I've been always hand-assembles their own CD story using off the shelf stuff, and so if one has compliance needs then Apollo allows to pay to have the "hand assembled" problem go away. That said, I have _absolutely no idea_ how much Apollo costs, so I'd also speculate that most organizations would be much happier just paying for a competent DevOps role to do the best they can to use off the shelf tools to hand assemble their own CD story, or use BigBang[1] which is at least open source and a standard (one may not like it, but it is at least consistent)
1: https://github.com/DoD-Platform-One/bigbang#readme
