Or perhaps they want to check the user's password choice against a multilingual dictionary, and they decided to save the user the multi-megabyte download?
If I were in charge of both requirements and implementation I'd debounce the input by 300-500ms and display a "loading" spinner in the password complexity box until the debounce timer and network request had fully resolved.
I was just trying to explain why, given some business use-cases, doing password validation on the client isn't always possible.
I prefer seeing one system or the other, but not both.
If you have rules, don't use a password strength meter. Rules are going to be a binary result - "yes the password is good enough", or "no, this password is not acceptable" - which is represented by showing which rule(s) were not respected by the user, or a green checkmark.
A password strength meter can be used when there are no rules enforced, to let the user decide for themselves whether that red progress bar showing a weak password is good enough for their needs. The meter doesn't need to be binary, with red/orange/yellow/green stages. The only reason I don't like password strength meters in general is that there is no standard across sites/services as to what constitutes a strong password. One site will show "password123" as weak, while another will say it's fairly strong. Each implementation has its own arbitrary algorithm that is likely not representative of "true strength".