You might contact the site owners and ask them specifically what's up with the arbitrary requirement. Actually, ask them specifically what password hashing algorithm they are using to create a digest of your password and how they are computing and storing the salt.
Maybe I'm overreaching a little, but my point is that if their system is secure because it is obscure, then it isn't secure.
I would't use the same password for that system that you use for your online banking, but then that's good advice across the board (different passwords for different sites).
Regarding the maximum length, accepted primitive hashing algorithms like the SHA algorithms don't care about the input length, and the output length from those functions is constant regardless of the size of the input, whether the input is three characters or the entire Encyclopedia Britannica.
If you want a 100 character password, you should be able to have one.
Them limiting your password to 16 characters tells me (right or wrong) that they're probably storing your plaintext password and the field they store it in is 16 characters long.
EDIT: Or it could be a sign that they're doing something along the lines of the old LanManager password hash algorithm, using your password, or diced-up parts of your password, as keys for a symmetrical cipher like DES or AES to generate fixed-size password hashes. That could be done right, or done wrong. Are they using salt at all? Are they preferring a speedy hash algorithm (NOT a good sign if they are) over algorithms designed for password hashing, such as scrypt/bcrypt/pbkdf2? Etc.
Further, spaces and slashes aren't any different from any other characters, unless they're doing something like using the password value for a file name (maybe a temp file name) or passing it around embedded in something like SQL or JSON, in which case they'd be concerned with having to properly escape those values in the string or break their software.
What they should be doing is handling the password as binary data, encoding it as necessary if they have to pass it from one component to another (e.g. Base64), and never keeping the actual unhashed password around even in RAM any longer than necessary, then storing the hash. In the case of SHA-1 (theoretically broken now), the hash is 160 bits long, although there are proponents of truncating the hash before storage (I'm not entirely sure I'm in that camp, but it's probably okay and that's a different issue).
Security is hard to do right, often done wrong, often neglected or treated lightly and this system sounds fragile, to me, on top of all that. I think you're right to be suspicious of it.