The password hashes buy you an improvement for the narrow range of passwords that are bad but not that bad against adversaries who are powerful but not that powerful. It's pretty much the definition of a marginal win. Which hash you choose slightly tweaks the margin.
It's essentially impossible that this is the lowest hanging fruit for your system security and so "use a different password hash" ought to be nowhere near close enough to the top of the TODO pile to get done if you're already using any of these decent password hashes listed such as PBKDF2.
If your users have strong passwords (e.g. a 20 alphanumeric random password from a typical password manager) it makes no difference at all. Even plain MD5() of such a password is as safe for the user and for you as Scrypt or Argon2 or other choices.
If your users have very weak passwords then once again it makes no difference. Your heavily tuned Scrypt password hashing doesn't prevent me guessing that Steevo412's password on your site might be something obvious like "letmein" - on a lowly mid-range laptop before I get bored.
So all this work is to achieve a marginal improvement in the middle. Maybe if Steevo412 has picked "LetMeInNOW" and maybe the script kiddies who stole the database ran out of stolen Amazon credits, they don't "crack" his password this time. Maybe.
And none of this makes you any safer from inadvertently leaking the plaintext passwords, which your system unavoidably needs to know during authentication, or numerous other pitfalls that have nothing to do with dick-measuring contests about which hash is better.
OR if security actually is important you could deploy something that's actually a clear improvement such as WebAuthn and stop trying to sweep the problems with password storage under increasingly complicated rugs.