That's just the point. Selfhosted runners were the alternative. The only alternative for "runners" is Github-hosted, 200%-markup runners.
Now the only alternative is to move builds, CI, etc. off of GitHub's platform entirely, and maybe your source control as well. In other words, a big pain. Github seems to have entered peak encrapification: the point where they openly acknowledge rent-seeking as their product approach, fully deprecating "building the best, most reliable, trustworthy product." Now it's just "Pay us high margins because the effort to migrate off is big and will take too long to break even."
Genuinely curious about this as well. It's a major bummer that self-hosted infra can't be used to validate GitHub Pull Requests now; basically means I'll have to move my entire workflow off of GitHub so that everything can be integrated reasonably again.
That's not exactly true. You just won't be able to use self-hosted infra to validate GitHub PRs a) using GHA and b) for free.
GitHub still supports e.g. PR checks that originate from other systems. We had PR checks before GHA and it's easy enough to go back to that. Jenkins has some stuff built in or you can make some simple API calls.
We use a combination of GHA and Jenkins jobs. All these end up as checks on GitHub. You could then proceed to say "Allow this PR Merge button if check A is ok and check B is ok" where check A arrived from GHA and check B from a Jenkins job.
Gitea + Gitea Actions works approximately as well as GHA. For GitHub specifically, you're back to setting PR checks + commit status programmatically through the API.
