It's important to have the main branch pointing to a good, stable commit in GitHub flow because that's what GitHub flow says.
Generally speaking, we give things names to make it easier to talk about them. People have developed branching models like Gitflow and GitHub flow to solve problems that they were experiencing on their teams or in their organizations. By giving these sets of rules, policies, and norms a name, they make it easy for people to talk about or discuss the pros and cons of the approach. If you say "Gitflow" or "GitHub flow" to someone familiar with the concept, they already understand how you work with no further details and someone who doesn't know about it can easily find reference material.
If you don't like the approach in GitHub flow, then perhaps Trunk-Based Development is a more suitable approach. This approach centers around commits to the main branch and creating release branches for release hardening and patching while allowing the main branch to continue along for the next release. Their website provides quite a few details into their rationale and even when it's not appropriate to use their model.
To answer your specific questions:
Why is it important to have the main branch always pointing to a good-to-go-commit?
It's not. See Trunk-Based Development for an example where the head of the main branch may not be a "good-to-go" commit, depending on the practices of the team and the requirements to release. It is, however, a requirement of GitHub flow because that is the definition of GitHub flow chosen by the creators.
Why can't we rely on the tags on the merge commits to point us to a ready/stable version commit?
There's no reason why you can't. I'm not sure if there's a well-documented and widely used version control strategy that takes this approach - I can't think of one at the moment. However, GitHub flow has chosen to not rely on the tags, but to rely on the head of the main branch to reflect the most recent stable release.
What is the added value of a git ref pointing to the latest good commit?
Easy access. It's a common theme across branching strategies that it's easy to access the "good" or releasable (or released) commits. Whether that's the head of the main branch, a tag, or a release branch (perhaps also using tags for patch releases). It doesn't matter how it's achieved, just that the people using the repository understand the structure and how to create a build of a given quality, either a release build, a release candidate, or perhaps bleeding-edge development.
