> escape data to prevent it from being interpreted as code

What about too much data? Overflow is a concern, too. Escaping is just one solution, so I shot for the more general rule.

> What about too much data? Overflow is a concern

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? ;)

"e.g. I can echo any evil input if my character encoding is enforced and HTML special chars are escaped as entities."

FAIL :-P

AFAIK You need to JS escape anything that goes into a JS context too.

You're right - escaping is very dependent on context, and sometimes you need to escape data multiple times in nested contexts.

In inline script you need to get JS string escaping right and avoid </ sequence that ends HTML CDATA.

And if you send that data from JS to the server, you cannot rely on the theory that JS massaged that data first.