By default, the answer of a question of the form can [bad thing XYZ] happen with passwords is yes. There is always a room for specific comments, but the fact remains that passwords are one of the least natural security tasks given to a person, and that person will, almost certainly, favor efficiency over security.

If you choose a long password that is not in a dictionary, chances are that the password is a random string of characters that are hard to remember. As a result, the user will need to find shortcuts to actually use his system without too much hazzle (for users, security is normally an obstacle to achieve the tasks that actually have value): write it down, keep it on the clipboard, plug a USB dong that types the password automatically... you name it.

The Battery Horse Staple XKCD comic became famous at producing longer passwords that are more memorable, but, as a result, put correcthorsebaterrystaple into every dictionary. So, in general, it is hard to produce usable long passwords.

That's it for the practical liability. Now let's see a bit of numbers. Let's suppose that you don't store your password in plaintext, but you hash and salt it. In general, let's say that there is no easier way to crack the password storage than obtaining a collision for the stored password. In that case, each password hash will have a fixed length: let's say 256 bits for SHA-256. Then, you have at most $2^{256}$ values to store. Granted, that's a lot, but that's also your "limit". If you store passwords with more than 256 bits of entropy, you'll not keep that additional entropy anywhere. It is not less secure, but, as the answer of Neil pointed in relation to bcrypt, there won't be any gain from longer passwords.

By default, the answer of a question of the form can [bad thing XYZ] happen with passwords is yes. There is always a room for specific comments, but the fact remains that passwords are one of the least natural security tasks given to a person, and that person will, almost certainly, favor efficiency over security.

If you choose a long password that is not in a dictionary, chances are that the password is a random string of characters that are hard to remember. As a result, the user will need to find shortcuts to actually use his system without too much hazzle (for users, security is normally an obstacle to achieve the tasks that actually have value): write it down, keep it on the clipboard, plug a USB dong that types the password automatically... you name it.

The Battery Horse Staple XKCD comic became famous at producing longer passwords that are more memorable, but, as a result, put correcthorsebaterrystaple into every dictionary. So, in general, it is hard to produce usable long passwords.

That's it for the practical liability. Now let's see a bit of numbers. Let's suppose that you don't store your password in plaintext, but you hash and salt it. In general, let's say that there is no easier way to crack the password storage than obtaining a collision for the stored password. In that case, each password hash will have a fixed length: let's say 256 bits for SHA-256. Then, you have at most 2²⁵⁶ values to store. Granted, that's a lot, but that's also your "limit". If you store passwords with more than 256 bits of entropy, you'll not keep that additional entropy anywhere. It is not less secure, but, as the answer of Neil pointed in relation to bcrypt, there won't be any gain from longer passwords.