I think the response there from Maxim hints at some of the problems I’m hinting at with the Travis-CI integration, but he doesn’t mention the one I suspect is most serious (and it looks to me like it might apply here): long cycle times.
If you look through some of their PRs that affect VM images (or look at the build runs, you’ll see Azure pipelines jobs that are multi-hour image rebuilds. If they handle updates and testing this isn’t a huge deal. If updates never break, it isn’t a huge deal. But if we need to iterate on a fix or new functionality we can’t test locally, very few people are going to want to mess with it.
It’s not for quite the same reason, but I call the Travis-CI process clunky because we have to wait for a human (who keeps US workday hours) to deploy our PR to their testing server; we then have to trigger a CI job to test it out and either let them know it’s okay, or iterate (and ask for them to re-deploy).
Feedback on changes to an action is near-instant in comparison.