It's often just a reflexive behavior on a website. Fields which have to be displayed back to the user naturally tend to have reasonable restrictions on what characters they can contain (no linebreaks is a common one, for example). The fact that passwords will never be displayed back to anybody (ideally) is no deterrent to your typical business analyst writing a hundred page spec for the account management pages, and just like every other field on the site they will place some arbitrary length restriction on the field, and pronounce that certain special characters are off limits. Programmers will then implement the restrictions because hey, it's an easy two points.

There are, actually, a couple of reasonable UX reasons for placing some restrictions on the characters someone can use in a password. If you hope that they will be able to enter the same password from another device later, you want to encourage them not to exploit all the wonderful input possibilities afforded by their plug-in emoji keyboard on their phone. Sadly I don't think this kind of reason underlies any restrictions I've ever seen in the wild.

Password has to be compatible with phone input -- legacy 0-9 phone, not mobile computing devices.

Why would this need to be restricted to A-z 0-9? Isn't it safe to assume that nobody will be typing in passwords from their land line?

I can give the quantum of the benefit of the doubt and assume that they're just possibly overly defensive for SQL injections if they're using the DB to do the hashing. They should be using parametrization anyhow and HAND, but maybe they missed that memo.

>When a site insists that certain characters are not allowed in passwords, that is strong indication that they are storing them clear-text in text files.

Except it really isn't, while stupid this is hardly uncommon in software that does hashing.