I guess what I wanted to say is that gitlab's CI/CD solution makes more sense because it was specifically designed for CI/CD, while I seriously didn't understand what problems github actions were intended to solve when the beta started. Only roughly a year later a simple CI/CD system was bolted on as an afterthought. This isn't a showstopper, but it makes the overall system needlessly complex and hard to understand if all you need is a CI/CD solution.

When I worked with gitlab CI, I've read through the documentation, understood immediately how it works, and had a pipeline up and running half an hour later.

When github actions was started, I approached it with the same mindset as I approached (for instance) travis.ci, AppVeyor or gitlab CI. But after reading through the github action documentation I had no idea how to make this work for a CI/CD workflow, so I ignored it and continued using travis.ci and AppVeyor for my github projects. Only roughly a year later the above mentioned CI/CD support was added to github actions, which finally made it useable in the same way as all the other CI services.

So my suspicion is: github actions was going to be a new "revolutionary" thing with a much wider scope than existing CI/CD solution. But most people didn't understand such a "visionary" concept, and instead just wanted a simple CI/CD service similar to all the 3rd party solutions that already existed, only better integrated with the rest of github.

And that's why I think that gitlab's integrated CI/CD service makes a lot more sense. It was much more focused on the developer's needs from the beginning.