The documentation in the Security class is likely at least partially left over from a previous version. Additionally, the wording could be improved in both portions of the documentation, as xss_clean() is not "filtering" the data in the way that term is typically used when discussing security.
The mantra for secure handling of data is "filter input, escape output". This tends to be confusing, because we might see xss_clean() referred to as XSS filtering or we think of input strictly as user input from a form and output strictly as output to a view.
"filter input" can also be thought of as validation. Make sure the data that comes in is valid for the intended purpose. If a field is supposed to be a number, don't allow letters. If a field is supposed to be an email address, make sure that it's at least conforming to the basic requirements of an email address. If any of the data is not valid, reject it. It's up to you whether any given piece of data is important enough to reject all of the input or just the invalid part.
Additionally, "input" is form data, $_POST data, $_GET data, or the URI, which is all more or less what we expect, but it's also the data retrieved from your database, from a file, or basically anywhere else. You have to define your own level of trust at some point, but at the very basic level the arguments passed to a public method in a controller, data retrieved from the database, data retrieved from a file, or data received from a third-party library should be treated the same as form/$_POST/$_GET/URI data (especially public controller methods, since they are accessible via the URI).
"escape output" means you process the data to be output and escape anything in that data which might be dangerous in the destination format. The method of escaping data is specific to the output format, as is the potentially dangerous content which must be escaped. In most cases, the text used to perform a SQL-injection attack is perfectly safe to output to HTML, just as the text used to perform an XSS attack is perfectly safe to store in the database. Most escape routines can only be performed on the data once, and some can be difficult to reverse. They also have the potential to render the data useless for other purposes.
As hinted above, we commonly think of the "output" portion as an HTML page, or maybe JSON or XML in specific instances. However, our SQL queries (or those generated by query builder) are also a form of output. The data inserted or updated in the database is a form of output. We may also write to a file or generate a file for download. We can even think of anything we pass to a third-party library as output. Even a redirect should be thought of as output, since we output a set of headers telling the user where to go next and quit.
So, xss_clean() should be used on data to be output to an HTML page, or any other format in which it proves useful. However, you need to consider the performance implications and the risk of the data to be output. If the risk is high but the performance is a potential issue, you may need to consider caching the output of xss_clean(), but you need to do it in a manner which permits purging/regenerating the cache if xss_clean() is updated or additional measures are required to escape the output.
