Issue #1 has a pretty solid write up by the author for why not dgraph or cayley[0]. In this post the author also mentions it's a rewrite from Java (which is quite obvious if you look at the code). I hope the project becomes more idiomatic Go as the author learns the language. In scenarios like this where a project for the author's learning and not necessarily production use, I wish GitHub had a better way to distinguish this from stable software looking for adoption.
Then again, Linux started with a newsgroup post that read:
"I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones."
If there was a "student ghetto" for open source, it might even be more harmful in net: overly humble creators would feel their good projects belong there, while the self-promotional extroverts would focus on getting their crap among the "real projects" just for personal fame.
I think the distinction isn't so much between "student/hobby projects" and everything else, so much as it is between "projects that go through the motions overly-formally to learn the motions, rather than to achieve the goal" (i.e. the result of doing a code kata) and projects that are created with intent to put them into—at least hobbyist—production. Even quickly dashed off scripts are useful to others; while perfected, deliberate homework assignments usually aren't.
Partitioning the search results of sites like GitHub based on such a factor might be useful.
You're right, though, that people wouldn't know well-enough at the time to self-report this "is practically-applicable rather than an academic exercise" property. It'd be more useful as a fact derived from social-bookmarking/tagging of repos, I think.
GitHub already has a pretty good signal for practicality in its "stars"; people don't star things that aren't useful to them in some sense. You could maybe add some other explicit signal (maybe a "hide" button in the search results) to serve as a negative signal.
Better yet, though, you could build some sort of "BlackBoard for CS" education-workflow site on top of GitHub, and use its positive signals (this is academic) as the negative signal for GitHub itself.
(As an aside: I've always wondered why more sites don't use this approach. It's way easier to incentivize people to tag something they want vs. something they don't. Build a second frontend for your site that serves the user-base you don't want on your main site, and serves them better—and then have that frontend add the ghetto-tag to everything it passes to the backend.)
[0]: https://github.com/krotik/eliasdb/issues/1#issuecomment-2494...