Since Filter.NET is a framework dependent on .NET 2.0, you may run into CLR versioning issues if any of the AppPools contain virtual directories configured with ASP.NET v1.1. While this is unavoidable in IIS 5.x when subscribing to SF_NOTIFY_READ_RAW_DATA, it can easily be overcome in all other cases.
As you may know (or not know) ISAPI filters can be installed at global scope or site scope. Global scope means that every single request gets filtered by the ISAPI, while site scope means that only requests for that specific site are the ones filtered. ISAPI Filters that subscribe to read the raw data (only available in IIS 5.x) are required to be installed at global (or server) scope. All other filters can be installed at site scope.
But we're talking about CLR versioning issues, like having ASP.NET v1.1 and ASP.NET v2.0 running on the same process. What does this have to do with sites?
Just make sure you organize your IIS sites (and virtual directories beneath it) by ASP.NET version. Then, organize and assign the AppPools accordingly. Having done that, and to avoid CLR versioning issues, you can safely install Filter.NET at the site level on the sites that have ASP.NET v2.0 (and ASP, PHP, CGI, PERL, ect...)