On the server side the password is often hashed multiple times, with brcypt so calle stretches. From the documentation of my web framework

"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.

That's not really a good reason, though. If you're running a high-traffic website you should already have a way to shed load and terminate long-running requests and threads. But "long-running" is subjective and depends on the environment.

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.

No, that has nothing to do with password length.

You're right, I checked old emails.

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.

Nice. There are lots of ways to speed that up, though. Use tries, or hash both your user's passwords and the list. (So that they're all the same length, and you never care about substring matches.)

I've had sites tell me when resetting a password that my new password is too similar to one of my old passwords (not even the previous one.) Far too many sites do something similar to substring searches.

That is an entirely different can of worms :)

Websites that limit password length or use those innane password requirements are the bane of my existence. They force me to create stupid passwords with symbols and weird capitalizations that I will never remember, forcing me to write them down somewhere or manually add it to a password manager. For many people, it's more convenient to just reset the password every time they need to use these websites because of their bs password requirements.

Or you could just use a password manager...

Also, why limit special characters? I've run into several websites not let me use characters like exclamation marks.

There really isn't a good reason. After all, once you hash the passwords they're all the same length.