It's up to the site operator to tune the cost; it's generally recommended 100-250ms depending on how much you're willing to make your users wait.

FWIW there are ASICs now that will get orders of magnitude faster hash throughput than your servers.

This is true, except for scrypt, which is very tough to make ASICs for. As for bcrypt, it's true that ASICS can go very fast, but you ultimately have a massive advantage as defender here. An attacker needs to try billions of combinations per hash, but you can simply take a whole second of CPU time (scaled to your current load, roughly) if you want -- that's not a lot for a user, but for an attacker taking several billion of even half a second makes cracking very, very hard.

You aren't technically wrong (the algorithm can add some number of bits of effective security), but that's still horribly misleading. "P@ssw0rd" is emphatically not a good password, and "because it has lowercase, uppercase, numeric and non-alphanumeric values" does not (significantly) improve a password. See https://www.explainxkcd.com/wiki/index.php/936 for a specific example. (But note that you need eight or more words if the attacker has password hashes that they can attack offline.) Salting adds 0-2 words worth of security depending on how many users can (no longer) be attacked with each hash invocation and a good (slow and optimization-resistant) algorithm adds 1-2 words depending on how slow you're willing to make login.

Edit: I think TFA might be being facitious in the claim "This is a good password because it has lowercase, uppercase, numeric and non-alphanumeric values plus is 8 characters long.", although it doesn't communicate that very clearly.