"Note that, for bcrypt (the default algorithm), the cost increases exponentially with the number of stretches (e.g. a value of 20 is already extremely slow: approx. 60 seconds for 1 calculation)."
With a high security configuration server side and allowing long passwords you can open the possibility of DDoS attacks: the attacker could create many account effectively consuming all CPU cores.
That's my understanding. I chose the latest recommended value, I think 11, ran tests with 128 character passwords (the limit I set) and was ok with the performance. Tested 1000 character passwords as well and indeed the website became unresponsive.
Other websites might use older configuration based on older recommendations or hardware specs. I'm not saying that's the explation, but it's one of the reasons.
The 1000 character password issue was something different: we check new passwords against most common passwords (a long list) in the browser before submitting and checking long passwords frooze the browser. The algorihm tries too many substring matches.
The recommended work factor for bcrypt is based on a lot of assumptions, and again, for a high-traffic high-value website you should be setting your bcrypt work factor to something that arrives at a target time for verifying a password is short enough to not annoy users but long enough to deter offline cracking. But how long is "long enough"? It depends on the value of your data. If you're storing Top Secret data, you should assume attackers have nation-state level resources and patience and your users are willing, or required, to accept response times that wouldn't be acceptable to consumers.
So the short answer to "why limit password length?" is that there's no good reason if you actually care about the tradeoffs between security and user experience.