The real problem is that if the password is too long, it will kill your server to compute a hash of it. So there needs to be a limit. The usual limit in my apps is 1KB. bcrypt is fast enough to hash 1KB with a work factor of 10 (a reasonable default on current hardware), and I have yet to come across any realistic situation where a password over 1KB is needed. After all, the heat death of the universe will probably occur sooner than you can brute-force it.
I'm willing to increase the limit a bit if someone really wants to use a 32KB password. But 1MB is probably overkill. 1GB is definitely off limits.
There is, however, another problem with using bcrypt to hash long passwords. bcrypt ignores everything after about 60 bytes, so the password is effectively truncated. This can be a problem if most of the entropy is in the last part of the long password, because long passwords that only differ at the end would produce identical hashes given identical salts. (Imagine that someone uses the Fifth Amendment as his password but changes a few words in the last clause. What if someone types in the unmodified Fifth Amendment? Boom, they're logged in.)
My current solution for this problem is to do something like bcrypt(sha512($password)) so that I never need to feed anything really long to bcrypt. (The raw binary output of sha512 is 64 bytes long.) But I'm not sure whether this might negate the benefit of using a very long password in the first place, so I wouldn't recommend it unless someone who knows better can confirm that this is safe to do.
No. This allows for DOS if there is no limit whatsoever: https://www.djangoproject.com/weblog/2013/sep/15/security/
But acceptable limits are in the kB range, not in the double-digits bytes range