A limit is recommended simply to avoid exhausting resources on the server.
Without a limit, an attacker could call the login endpoint with an extremely large password, say a gigabyte (let’s ignore whether it’s practical to send that much at once. You could instead send 10MB at a time, but more quickly).
Any work the server needs to do on the password will now be that much more expensive. This applies not just to password hashing but every level of processing to reassemble the packets and get them to the application. Memory usage on the server also increases considerably.
Just a few concurrent 10MB login requests will start having an impact on server performance, perhaps to the point of exhausting resources and triggering a denial of service.
These may not be security issues in the sense of password/data leakage but crippling a service by DOS or crashing definitely is. Note that I make no mention of buffer overflow: decent code can handle arbitrarily big passwords without overflowing.
To wrap up, I think when someone says “there’s no reason to limit the number of characters of a password”, they are talking about commonly seen small limits (eg: 10 or 20 characters). There is indeed no reason for those other than laziness or working with old systems. A limit of 256 characters which is larger than desired by most people (except those testing those limits) is reasonable and can prevent some of the issues related to arbitrarily-large payloads.