Yeah, the missing context is that we are talking about vectors where GitHub would not be sanitizing the input correctly. In other words, vectors that traditionally resulted in XSS. We do exactly as you say in places where we expect user controlled input. For example, all issue/pull request comments are Markdown. And, for security, we go to great lengths to ensure that we only accept a subset of HTML that is safe AND that the resulting HTML is well formed. But, as history has shown, XSS is more or less unavoidable. There are just too many places where it can occur for any application to 100% avoid it. This is at the heart of CSP. Given that history has shown that XSS was unavoidable, the idea was to add a browser feature as a second line of defense. So, the article is written from the perspective that traditional XSS is neutered (the whole "scripting" bit of XSS is gone) using CSP. So, given that, what might an attacker be able to do without injecting any JavaScript? This is the origin of "scriptless attacks". Dangling markup is the most popular technique for exploiting a scriptless attack. So, it isn't that GitHub would be failing to create well formed HTML. It would be a scenario where an attacker would traditionally like to have injected a `<script>` tag, but is no longer able, so they must go to the next best thing...dangling markup.
XSS is unavoidable if you think the solution is sanitizing user input.
The solution to sql injection is parametrized query construction, instead of automatically filtering the ' character and then pasting the template and the user input together.
Similarly, to avoid cross site scripting you have to combine your templates and user input by escaping it properly, instead of just concatenating them and then hoping you can avoid the issues by input 'sanitizing'.
