I once worked on a game (Pokemon GO) that went from zero users to over 100 million users in a bit over two weeks.
Scaling was still very, very stressful but it wouldn't have happened at all without Kubernetes.
Perhaps another good example is how voat failed to capitalize on reddit's mass exodus because mostly their service was rendered unusable by their apparent inability to scale.
As an aside I think Voat failed because the community that came was toxic and the team behind it had no intentions of quelling it. https://gizmodo.com/goodbye-and-good-riddance-to-voat-reddit...
There is much less in terms of cognitive load on the developers, fewer moving parts to know about. Importantly the ability to use the same docker-compose.yml for develop, debug, build, deployment comes with the immense value of the boring sameness that a production deployment should have, and not having to worry over 'one more thing' or 'one more moving part' or 'one more translation layer'.
That all said, figuring how to do this yourself or how to adopt solutions for other platforms can be _fun_. I find it fun. I wish more people found it fun, and believe we'd have a more diverse, vibrant infrastructure ecosystem if most other people also found it fun. In practice, however, I've found that few people find this fun, and those that do have no time to have said fun. Most users I work with ask a combination of "can you provide idiot-proof instructions for this?" and "have other people done this already to hash out the difficult bits?".
For a variety of reasons, Swarm lost the popularity war, and so it doesn't matter what, if anything, it does better.
+1 on Docker Swarm. Although it does have its kinks, it's far simpler to get working, has a smoother learning curve, and does the job well.
I would argue that Docker Swarm is ideal for those cases where it's unlikely you'll need a lot of autoscaling or operate a large cluster.
You probably didn't need "container orchestration"