There's nothing special about PBKDF2. It can -- and should -- be replaced with more modern algorithms like Argon2 whenever possible. PBKDF2 is not resistant against brute-force attacks with GPUs and specialized hardware (ASICs).

However, unlike Argon2, PKBDF2 is standardized in the W3C Web Cryptography API and implemented in browsers. For Argon2, there doesn't even seem to be a canonical JavaScript or WebAssembly library, only a couple of GitHub projects which may or may not be production-ready. This is a very good reason for preferring PBKDF2 in this specific case.

Note that client-side hashing is a rather exotic feature which only helps in very specific scenarios. First off, from the server's perspective, the client-side hash is the password. If an attacker can provide the hash, the server will happily log them in. It's not necessary to know the original password. So the client-side hashing doesn't protect the authentication of your application at all. At best, it protects the password itself, which is only relevant if the password has been reused and allows an attacker to gain access to other applications as well (which of course should never happen). And even then the protection is very limited. If an attacker can exploit vulnerabilities in the client-side code, they're likely able to comprise the entire authentication procedure and capture the password before it's hashed. If the server is malicious, then nothing prevents them from disabling the client-side hashing. The only scenario I can think of is that client-side hashing protects reused(!) passwords in the short window when the server has received the password but hasn't hashed it yet.

There's nothing special about PBKDF2. It can -- and should -- be replaced with more modern algorithms like Argon2 whenever possible. PBKDF2 is not resistant against brute-force attacks with GPUs and specialized hardware (ASICs).

However, unlike Argon2, PKBDF2 is standardized in the W3C Web Cryptography API and implemented in browsers. For Argon2, there doesn't even seem to be a canonical JavaScript or WebAssembly library, only a couple of GitHub projects which may or may not be production-ready. This is a very good reason for preferring PBKDF2 in this specific case.

Note that client-side hashing is a rather exotic feature which only helps in very specific scenarios. First off, from the server's perspective, the client-side hash is the password. If an attacker can provide the hash, the server will happily log them in. It's not necessary to know the original password. So the client-side hashing doesn't protect the authentication of your application at all. At best, it protects the password itself, which is only relevant if the password has been reused and allows an attacker to gain access to other applications as well (which of course should never happen). And even then the protection is very limited. If an attacker can exploit vulnerabilities in the client-side code, they're likely able to compromise the entire authentication procedure and capture the password before it's hashed. If the server is malicious, then nothing prevents it from disabling the client-side hashing. The only scenario I can think of is that client-side hashing protects reused(!) passwords in the short window when the server has received the password but hasn't hashed it yet.