Since my first question missed the mark, I provide a separate answer. The primary reason is that limits are required. Although the concern regarding the storage space and achunk of data is accurate, there are some issues.
First, if you read my original answer below you will see that one of the recommendations is iterative hashing (i.e. pbkdf). This requires a large number of iterations in order to be truly effective. If a user is able to submit a large string, then the cost of computing this iterative hash value quickly becomes more expensive than expected for a simple authentication function.
Any single computationally expensive task on a server, especially one that is explicitly available for an unauthenticated user, is subject to abuse by a malicious user to perform a denial of service attack.
Second, by implementing a fixed length password it provides an opportunity to terminate early if an extremely long request is submitted. If the parameters in the request are outside of the expected length it is simple to issue an error message and close the connection.
The reason that password complexity requirements are enforced on many sites is to prevent users from choosing a weak password. There are numerous examples in recent history which show that most users will select weak, easy to enter, easy to remember passwords over complex passwords. When this occurs, the owner of the site is placing themselves at risk as users will invariably blame the site if a password is stolen or cracked, and whatever outcome that may have to both the site and the affected user.
By implementing strong password requirements, it reduces the likelihood that an attacker can easily guess the password. Passwords also need to be protected against two different attack paths. The first, online attacks, requires that a site developer have a policy that will prevent brute force attacks from succeeding. This is accomplished by requiring that a user select a suitably long, complex password, and restricting the number of failed logon attempts before slowing (i.e. temporary lockouts, captchas, etc) or stopping attempts to login (permanent lockouts, mandatory password reset, account confirmations, etc).
The second attack is an offline attack, where an attacker will acquire a copy of a password database, and attempt to use a rainbow table or offline password cracker to crack multiple accounts. This type of attack is prevented by using a strong hashing algorithm in conjunction with a per-user salt, and preferably pbkdf2 or bcrypt/scrypt style rehashing to increase the computational cost of offline cracking.
Ultimately, both of these techniques fail if sites don't encourage users to select a unique password for their various accounts. Many users will select the same passwords for multiple account, and when that password is exposed, especially with their email account, it is possible for an attacker to use that credential on another service. For this reason it is best to generate unique, strong passwords for each site, or at least different groups of sites and use a secure password manager to store all of the different passwords.