As you already know, Group Policy processes settings during computer startup and shutdown, and user logon/logoff. It also does a background refresh cycle every 90 minutes as the users are working on their computers throughout the day. The goal for Group Policy processing is to be as fast as possible, hopefully measured in milliseconds, so that your employees are not wasting time sitting around and waiting for these settings to finish processing.

To this end, in a normal GPO background refresh cycle, the computer evaluates whether or not GPOs have been modified. If they have since the last cycle, then of course the computer needs to spend time and energy processing through those modified GPOs. But if the GPO is completely unchanged from the last refresh, it can skip that GPO to make the process more efficient.

When you apply a WMI filter to a GPO, by nature of the way the filters work, you then cause that GPO to be reprocessed every time that Group Policy refreshes. This happens because the filter needs to re-evaluate the machine criteria every time that the GPO attempts to apply. This will have some form of performance impact, though hopefully very small. Some WMI filters evaluate within milliseconds, which probably won't be noticeable, but some can take full seconds to complete. It is important to always seclude and test GPOs with WMI filters applied before rolling them out to production, to ensure processing performance is within acceptable standards.

Try to keep WMI filters only applied to GPOs that are pretty selective to begin with. Appending a WMI filter on a GPO that only applies to a single nested OU is going to cause a very minuscule change in GPO processing, but setting a WMI filter on a GPO that is linked at the domain level instantly increases processing time on every machine in your network. Yikes!