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"