That's a reasonable answer -- but it's an answer to question I wasn't addressing. Whether github reinvents the wheel is not relevant to my point.
I was specifically debunking the illusion that "simplicity of the issues submission form == no cognitive overhead".
If the "issues creation" web form is lightweight, the submitters will eventually expend "cognitive overhead" by clogging up the threads with clarification messages.
If the project maintainer uses your solution of an external tracker, that means the submitter still expends cognitive overhead by noticing that the project's "issue tracking" has been disabled, and then reading front page README.TXT or CONTRIBUTIONS.TXT to figure out what external website he's supposed to use to submit issues. No doubt the web forms[1] on those external trackers will have the checkboxes and dropdowns that some people are suggesting people avoid.
The "cognitive overhead" required to clarify and provide meta-descriptions for bug reports is inescapable. You're only deciding whether it is structured or unstructured and where it is shifted.
Your reply is going in different direction from cognitive overhead and on that perspective, I don't know what makes the most sense. My guess is that many open source maintainers don't need a heavyweight tracker that can do things like assign tasks to multiple programmers, burn down dashboards, correlate activity hours to billing, etc. They don't need all that. They just want a template to improve how users file issues. Maybe a survey would provide insight as to whether your answer is the most sensible.
"Software lifecycle tool" is too vague for a product to have focus and open to too many interpretations as to what it should include. Even limiting scope to issue tracking, there are different points of view on how that should work and several widely-used but rather different software alternatives to choose from.
And how many teams spend the first three months of a project building a custom issue tracker because they don't like any of the off-the-shelf options? Trying to get issue-tracking "right" is a black hole for a company like github. Which is probably why they provide the bare minimum free-form issue and that's it.
