Welcome to the GitHub Support Community, @Lectem!
That’s a great question, one in which I don’t have a good answer for. Neither our documentation nor our GitHub Engineering blog offer an explanation for why it was designed that way.
Taking a step back from the question, I see where you’re coming from in relation to using statuses as a way of indicating the state of a particular change. While that particular link relation for
statuses in pull requests will continue to exist in its current form, it’s worth pointing out that status checks are based on external processes. They are designed primarily for our integrators who build applications on top of the GitHub API. The GitHub API provides a status API and a Checks API for these integrators and they’re welcome to choose whichever interface works best for their service.
In other words, GitHub provides the interface and integrators use that interface to inject the data from their service. Given that context, I suggest getting in touch with the person or team that developed the integration that you’re using in your repository and asking them why/how they choose to create commit statuses or check runs for the associated commits in a pull request. In that conversation, you could bring up this difference with them (testing the HEAD of the compare branch versus the merge ref) and see how they would approach this for their application.
Does this help?