So in a way, Yes, the AD Password Sync Agent overrides this.
In my case, the "No Import Match" is set to "Mannual confirm new user"
The users are being imported, but not activated. However, the next time a user changes their password on the domain (We are talking Ctrl+Alt+Delete, change my password, or password expired changed at login), the Okta AD password Sync agent will activate the user if the JIT Activation (which is Enabled).
Here is why, the Okta AD Password Sync Agent on the domain controllers does not use the Okta API to update the user's password in the Okta cloud. Instead, when notified by the domain controller about the password update, via the password filter API, the AD Password Sync Agent performs an login to Okta with the user's credentials at the [org].okta.com page. This login counts as a "AD Delegate Authentication" (see right side of attached jpeg) and triggers the JIT provisioning even though the end user never went to the [org].okta.com nor used an application managed by Okta.