It is still just fine to keep using bcrypt, scrypt, and PBKDF2 --- but it wouldn't make much sense for them to have a Password Hashing Competition and not conclude it by recommending some algorithm over all the others.
The real distinction isn't between apps that use the PHC winner and apps that use "legacy" password hashes, but instead between apps that use serious password hashes at all and apps that just use SHA hashes.
In fact, for the time being, I'd still recommend new development use bcrypt or scrypt (and not PBKDF2 for the simple fact that typical APIs around it aren't specifically tailored to password hashing, don't handle salts transparently, etc.). Argon2 winning is great, and it's almost certainly an improvement over existing methods, but it's also still relatively new and should be approached with typical caution.
For what it's worth, I'd say that the true winner of the PHC is scrypt: Half the candidates were just minor tweaks to scrypt, and nobody achieved any substantive security increase over what scrypt provides.
Only use PBKDF2 if you are comfortable with a function that a GPU-using attacker can evaluate many hundreds of times more efficiently (in terms of energy cost) using hardware that hundreds of times cheaper (in terms of $/guess/s).
Expressed in terms of log base 2, by using PBKDF2 you're leaving several bits of security on the table. And most folks agree that passwords need all the effective entropy they can keep.
Of which I'm a huge fan because you can easily build it out of stuff that any crypto library has. This is incredibly useful in certain situations where you need to check against passwords from different languages and environments.
Implementing bcrypt or scrypt from scratch if you have nothing to interface with is … tricky.
The real distinction isn't between apps that use the PHC winner and apps that use "legacy" password hashes, but instead between apps that use serious password hashes at all and apps that just use SHA hashes.
Still: an interesting development!