Yep, this mostly works fine (and can be necessary already in some setups anyway), the main issues are that each status update requires an API call (over v3, AFAIK updating statuses was never added to v4) so if you have a lot of statuses and PR traffic you can hit rate limits annoyingly quickly, and github will regularly fail to deliver or forward webhooks (also no ordering guarantees).
We have internal integrations with GitHub webhooks that will hit our server to checkout a branch, run some compute, and then post a comment on the thread. Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks, but you can receive webhooks and make API calls for free (for now). Would definitely result in some extra overhead to implement outside of Actions for some tasks.
> Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks
Post statuses, and add rulesets to require those statuses before a PR can be merged. The step after that is to lock out pushing to the branch entirely and perform the integration externally but that has its own challenges.
I mean maybe https://github.com/rust-lang/bors is enough to fully replace Github Actions? (not sure)