1) Never send untrusted data to the client.
How you do that isn't terribly important. It just matters that you do. Which is what that page is talking about: what you can do in order to never send untrusted data to the client.
Web developers would love it if there was a paragraph explanation that could explain how to prevent all XSS vulnerabilities in every site in detail, but there isn't.
1) Never trust what the client sends you.
AKA "How to prevent SQL injection and other such nasties"
Great counter-indication of software security: "We have no SQL injection. No way. You'd get fired." What that tells me? You're not looking out for SQL injection; you think it can't happen.
1) escape data to prevent it from being interpreted as code
Because this security problem is just subset of markup correctness problem.
If you escape data perfectly, then both trusted and untrusted data won't be misinterpreted, e.g. I can echo any evil input if my character encoding is enforced and HTML special chars are escaped as entities. I can send any untrusted nastiness to database via prepared SQL statement.
What about too much data? Overflow is a concern, too. Escaping is just one solution, so I shot for the more general rule.
Buffers are not supposed to overflow with trusted data either, so again, security is subset of correctness. "Not trusting" data only prevents exploit from reaching vulnerable code, it doesn't fix the vulnerability.
Don't write web applications C? ;)
FAIL :-P
AFAIK You need to JS escape anything that goes into a JS context too.
In inline script you need to get JS string escaping right and avoid </ sequence that ends HTML CDATA.
It might be nice to call this useful document something else, though. "XSS prevention summary" or whatever.