The other issue is that if I encode entities when inserting html, that means I have to call this on every page view. For simple strings that's not too big a deal, but if I have a lot of content, this gets resource intensive pretty fast for larger scale sites with lots of people hitting a page at once.
In this case I'd rather due the encoding once, which handles a majority of cases.
And you can't pre-encode a string without baking in bad assumptions that you know how it may ever be used. You're going to regret having your data store polluted with HTML-specific encoding as soon as you build an API or integrate a third-party tool (e.g., analytics or sales support), because they will need either raw values or some different encoding than HTML text (SGML entities).
I really don't like that word. Or "filter", "clean" or whatever people call it.
It implies that you can somehow run a variable through a filter and scrub of all the evilness. But that is not how to deal with the problem. What need be done, is to encode strings properly when embedding them in a context, that is interpreted in some other context. For example encode entities when inserting into html or urlencode when inserting into a url.
Bottom line is - This has nothing to do with user input. It has to do with how you output data.