Semaphore is one of the best CI/CD platforms in terms of:
1. Ease of use.
4. Their tremendous effort on pushing forward best practices.
Semaphore developers understand what you need from a CI/CD platform, and they keep improving it. Often they release new features I need before I requested them. This is particularly true if you look at their newly released 2.0 version. I'm a big believer of total infrastructure-as-code (IaC). Including CI/CD itself, they need to be part of IaC. With Semaphore (particularly 2.0), you can archive near-100% IaC.
A strong competitor is AWS CodeBuild. However, to use it effectively, it requires a large amount of prior work and the learning curve is quite steep. Please forgive my bias that I think the majority of the CI/CD users would not have time or resources to do CI/CD nicely with AWS CodeBuild. Semaphore CI will save you much time, in other words, much money.
My primary requirement of a CI/CD tool is that it has to support both Git Flow and non-Git Flow workflows. Because when it comes to managing deployment, I have a lot more deployment environments than just "master" and "develop". I also need to support rolling back quickly and efficiently for each environment. I can achieve all that with Semaphore.
The quality of most of Semaphore CI’s competitors is nowhere near Semaphore’s. One of them that I tried stated that it supports BitBucket on their homepage, but the BitBucket integration was broken utterly. Also, it was left broken for weeks. I wouldn't bother trying it anymore. Some competitors might seem to be more popular. However, I think this is an example that more popular tools are not necessarily better.
I was blown away on numerous occasions by their technical support. Last time, they helped me to resolve an issue similar to kernel panic inside a virtual machine in my CD environment in Semaphore (and yes nested VM because I was building a VM image for later use). Ervin, one of their engineers, provided a workaround to me in less than 24 hours. Then they went on to actually address the root cause. This is impressive because I think the issue I was encountering was very low-level and hard to debug. Remember we are talking about things like kernel panic here, not many developers would have any clues.