There is no advantage. A password-based KDF already behaves a lot like a hash function.
There is no weakness to pre-hashing a password if you use a proper hash function.
If the probability of a hash collision is small then hashing does not reduce a cracker's search space.
However, if the hash had a 16-bit output, then you would have a problem. A cracker would just guess-and-check each 16-bit KDF input, skipping prehashing, rather than guess-and-check different passwords.
On the other hand, if you use SHA-512 then you are not reducing a password cracker's search space. Hash functions aren't truly one-to-one functions, but we can safely say we have never hashed two distinct inputs that have the same SHA-512 output. You would expect humanity to have to hash around $2^{256}$ different messages (give or take slightly on that exponent) before it becomes probable that we would have two messages collide by chance. (That $2^{256}$ makes astronomically large numbers look infinitesimal by comparison.)
Until we generate that many distinct passwords we can get away with approximating the relationship between prehashed "passwords" and pre-prehashed passwords as a one-to-one mapping. That makes the prehashed password basically equivalent to the user's password. (Just in a different format.)
Guessing random 256-bit strings isn't a shortcut or a smart strategy. It still makes sense to guess and check plausible passwords by brute force. Again, the cracker's search space isn't reduced, so there is should be no impact on security.
Note that I said a hash with a low collision probability would be safe (but still pointless). You don't actually need collision resistance. If you used SHA-1 instead, that collision attack wouldn't necessarily have any impact on security. In most real world scenarios that would just mean a user could use more than one password to login to the same account or decrypt the same files. User chosen passwords or randomly generated passwords still won't result in SHA-1 collisions in non-adversial settings.
Aside: The security of password hashes and KDFs in general don't rely on collision resistance. You just need a function that is preimage resistant and that does not have any biases that reveal information about inputs. (Actually, for KDFs at least, biased output in general.)
A hash that wasn't preimage resistant would not work for user authentication. (A hacker could find a password that hashes to the same value. It wouldn't matter to him whether it was the same as the original password.)
A hash with biases might make a password cracker's search easier.
Password based KDFs like Argon2 utilize hash algorithms with these requirements.
Finally there are two scenarios where prehashing passwords might help. Just not for reasons based in cryptography.
First, there might be quirks in a KDF or password hash. For example, there might be a length limit on the password (as in bcrypt). Prehashing transforms the user input into a fixed length bit string.
Bcrypt has several issues related to user input. If you had to use bcrypt it would be a good idea to prehash a user's password with a 256-bit hash and encode the output using base64. That results in a pure ASCII string with no stray null characters that's small enough to be used with existing bcrypt implementations. (You should still use Argon2 because it's much better for password hashing.)
Second, you may opt for the client to prehash users' passwords before sending them to the server. Web applications typically receive the user's plaintext password, whether they use HTTP or HTTPS. Sending a hash of the password is not a substitute for encryption (because eavesdroppers can just send the same hash without ever requiring someone to log in with the actual password), but it potentially obscures the user's actual password.
If the user's password is weak then the server can guess the original just the same as any other password cracker would. If a password is inhumanly strong then the server won't ever know the user's actual password.
(Although that's unrealistic. If passwords are assumed to be that strong then there isn't the need to use a dedicated password hashing algorithm instead of an inexpensive hash. It's likely better to do client-side password stretching for non-web-applications if the server shouldn't be trusted with actual passwords. Or use an alternative authentication method.)