How to estimate the maximum computational cost bound for Key Derivation Functions (KDFs) before it becomes useless security-wise?
Generally we look at strength by looking at the order $O$ that it adds to the password search when an attacker is trying to guess passwords. That's just the same as the number of iterations basically, assuming a salt and correct password hash. Often it is simpler to just use bits, which is basically the $\log_2$ of the order.
So if a password strength is an average of about 40 bits, then you'd take the $log_2$ of the number of iterations and simply add the values together to get the resulting strength. So given 1048576 iterations, we'd get around $40 + \log_2(1,048,576) = 40 + 20 = 60$ bits of strength. Given the average weakness of passwords, there is no higher limit that is not entirely impractical. Obviously performing $2^{88}$ operations to allow for even average passwords to have 128 bits security is out of the question. So generally you should aim for the highest value possible for a specific service.
For the same reason it is very important to take other measures than just using a password hash with large iteration count. Possible measures are a max number of retries, an added delay before testing each password, requiring a good password with (likely) high entropy or using a password manager of some kind. Browsers nowadays offer internal password managers including generation for a good reason.
Note that some of password hashes such as bcrypt use a two-exponential &quot;work factor&quot; instead of an iteration count to give a better idea of the strength added to the password entropy in bits.