The only security-valid reason I'm aware of boils down to "to avoid DoS attacks against our slow password hash by uploading absurd amounts of password", and 60 is too low a limit for that to make a lot of sense.
The next-least-bad reason I'm aware of is "because users are dumb and if we let them use the entire text of Moby Dick as their password, some of them will, and then some of them will mistype some of it or think they used Don Quixote instead, and then they'll think they have completely forgotten their password and are either going to consume support resources or just stop using the site", which has at least the advantage of not assuming the users are any less intelligent than whoever came up with the password policy.
Or maybe they just can't possibly imagine anybody using an actual honest-to-$DEITY long passphrase. I'll be honest, none of my passphrases are longer than 60 characters; it's a pain to type that much. Heck, it might even only be a client-side limitation, put in by somebody who doesn't understand anything about password security but thinks they're saving space in the database.
All other reasons are bad signs, security-wise.
Some of them are more or less bad than others. Anything involving "to save space" or "the size of the field in the database" is a critical red flag; it means they're storing the passwords either in plain text or under reversible encryption, instead of even a minimal-quality hash. That means anybody who has access to their credential store - be it an untrustworthy admin, or any "hacker" who finds a SQL injection - can probably figure out every one of those credentials with minimal difficulty. Alternatively, they could "just" be using an obsolete password-hashing algorithm that has an inherent maximum length (still not good - those algorithms are obsolete for good reasons - but at least you'd probably need a rainbow table or a few hours of EC2 time to brute-force them).