The benefit of changing the SSH private key is that any person who (unexpectedly) obtained this key cannot use it anymore to read your traffic or to become man in the middle.
That's about the only benefit I can think of.
Since SSH doesn't operate in PKI regime (SSH public key are not certified by trusted public certificate authorities, unlike SSL/TLS), each change of SSH private key on a server requires a communication to all the clients to authenticate the new key to them. The clients usually "pin" (remember) the exact public keys allowed for a single server and authenticating a new public key is a human action. Deauthenticating an old key is another human action. Some of the clients are scripts usually buried deep, unmodified for months or years, and for a server to determine how to contact their human maintainers is another manual task.
As follows, the change of SSH key should be visible to server's admins, otherwise it's a bug. And you need a workaround (such as daily monitoring) if you have this bug.
It is valid to assume that SSH private key is not related to FTPS certificate.
It is valid to assume that SSH private key is subtly related to FTPS private key. If you change the latter it is quite obvious to assume that you think you face a breach of security. The same breach is likely to leak an SSH private key too. But still the keys are separate, so automatically changing SSH private key is an overshoot, really.
Side note: normally you can have multiple SSL/TLS certificates for the same SSL/TLS private key. The private key doesn't have an expiration date field. If you generate a new private key, you need a new certificate to be signed by publicly trusted CA.
In other words, when re-generating the SSL/TLS certificate, you could keep the old SSL/TLS key. Many inexperienced admins don't know this.