You can do that without having the repo and the issue tracker in the same product. For example, at work we use Jira for issue management and GitHub for code, and with a Git Jira plugin, they integrate pretty seamlessly in both directions.

Yes it’s nice, and there are dozens of products that allow you to do that. My point is that this is not the main value-add of GitHub, and discussions of “replacing GitHub” that center around re-implementing these features are missing the point. The value-add of GitHub is its community and years of developer mindshare. There is no simple technical solution to replacing that.

It feels like there might be two different uses of "coupling" here.

The linked article argues that GitHub locks in users by not storing everything in git, which what the post you're replying to is skeptical of. (I am, too.)

Being able to say "issue X has been solved in commit Y" is coupling the issue tracker and source control at a user experience level. The back end solutions are immaterial; they just need to be talking to one another, whether it's through plugins, or through proprietary features like GitHub already has (in which commits can be automatically linked to issues and vice-versa, merging PRs can automatically close issues, etc.).

That’s a matter of preference. A git repo will probably outlive fashionable-issue-tracker-of-the-day, so it might make sense to not embed this sort of information right inside git commits.