This is something of a philosophical question: "is control X helpful?" And as the best answer pointed out, you should also consider "what are the costs (client support, doc exemptions, system support, monitoring support, and I'd throw in direct costs, licensing costs, etc) of control X?"
Anything is helpful in certain contexts. It is a good idea to ask yourself what context you are in. Sometimes the context is one of compliance -- you are deploying control X to meet a particular requirement. "I've got to move my ssh port because system policy forbids listeners on port 22." Then either do it, file for an exception, or work to change the policy. [That would, imho, be an unwise policy.]
Here, the context is probably "I'm a random guy, with a host on an uncontrolled network, and I don't want to lose control of my box." Attacks always have an investigation phase -- if the investigation is "send a SYN on port 22 and see who answers" then you are protecting against that specific threat vector. (If the investigation is "perform a port sweep, collect banners, and see if anything interesting shows up" then your control is of no effect.) But now you have made a lot of work for yourself -- if you are using a tool to attach to the server, you need to figure out how to work on that non-standard port -- and with some tools, that might not even be possible. On balance, and in this context, I wouldn't recommend changing ports.
One benefit noted was reduction of log events associated with false positives. I actually find that a negative! The steady stream of inbound attacks on port 22 can actually be helpful -- if they stop, you know that there is a problem with your Internet feed. I think the perceived benefit is a false one -- the right answer is to tune your anomaly detection system to filter out unsuccessful login attempts from external networks.