1. In a sense, yes, since checking the password against a stretched hash will take more CPU time. But you should have some rate-limiting in any case to prevent brute-force guessing passwords, and while doing that, you can take into account the DoS potential. Also, login attempts will not be the only way to (try and) DoS something, you might get excessive load from other requests too, or just receive excessive amounts of network traffic, preventing legitimate requests from reaching you.

I think making it harder to crack the passwords in case of a leaked password database is worth the cost, but of course it is a trade-off.

2. I'm not sure what you mean by this. If stretching is prevented, password hashes cannot be checked, so it would be the same as denying logins outright.

1. In a sense, yes, since checking the password against a stretched hash will take more CPU time. But you should have some rate-limiting in any case to prevent brute-force guessing passwords, and while doing that, you can take into account the DoS potential. Also, login attempts will not be the only way to (try and) DoS something, you might get excessive load from other requests too, or just receive excessive amounts of network traffic, preventing legitimate requests from reaching you.

I think making it harder to crack the passwords in case of a leaked password database is worth the cost, but of course it is a trade-off. You have to take into account the expected amount of (valid) logins, and that the system can handle them. With millions of users, the stretching might start to take its toll.

2. Yes, if you rate-limit connection attempts and start denying them outright at some point, it would be useless work to run the hash fully for a login that is going to be denied. Though, returning a failure immediately will reveal via timing the fact that the password wasn't even checked.