In practice, there will be some part of the system that breaks first when a password or any other field tries to grow infinitely long. Having a defined upper bound from the beginning of the design means you have a testable requirement.
That said, there's no excuse for setting the upper bound so low that any human ever gets their actual choice for a password rejected.
It doesn't necessarily mean that they're storing it plaintext (ie it could simply be a front-end input validation). But in any case it doesn't inspire confidence that they're following best practices.
I'm somewhat skeptical of "we have a validation rule here, but it doesn't validate against any actual requirement, we just threw it in for the heck of it [image of dog piloting an airplane]." Even the bizarre "well, we have a CHAR(20) for the password, so we can't save anything longer" sounds saner than that ;)
To me, it always feels like they're putting up a humongous, blinking sign proclaiming "Proudly storing your passwords in plaintext since 1991!" (Most notable offender, last time I checked: Skype)