A bit of background first:
The reason why passwords are not stored as plain text usually is to provide defence in depth. That is, in the case of a database compromise (which is something that should obviously be prevented), it should prevent the attacker from gaining access to the original user passwords. This usually makes gaining access to the PBKDF2 secured passwords less valuable to the attacker. Of course, this only holds true when the passwords are strong themselves.
To answer your question:
As a result, the original premise of making gaining access to the hashed passwords less valuable does not hold any more since access to that information does have value (gives the attacker access to the victim users account). It has less value to the attacker than gaining access to the original password (before performing the PBKDF2 operation) but has more value than if it were encrypted on the server-side.
There are other problems with client-side PBKDF2 that I think should be mentioned:
- a static salt would have to be used (i.e. it cannot be random as it would produce a different PBKDF2 value)
- other values passed to the client-side PBKDF2 client-side function would also need to be static, thus removing a number of security features (such as changing the number of iterations)