I don't see a compelling argument why that REST API would necessarily be more secure.
However, that depends on implementation.
For instance SSH can be configured to require public key authentication and disallow password authentication.
Personally I enable SSH on the servers I manage but I only open port 22 to a few whitelisted IP addresses at firewall level (iptables, firewalld etc), that I control. So the only way to access SSH is by using one of my VPNs.
Do all this this and you've got a reasonably-secure setup - the attack surface is virtually nil.
How is access granted to that RESP API? By a user/password pair, a token, or some Oauth scheme? Note that a web service can also be restricted by using client certificates. Likewise, access to the API could be limited to certain IP addresses or address ranges, just like described above. That means access is only possible if you connect from a whitelisted location, or use VPN.
As you can see, the same techniques are available to both SSH and the API. The question is: is anything like this in place already?
Is there any protection against brute-force attempts? Just like Fail2ban can ban IP addresses attempting to brute-force SSH or other services. Fail2ban could also secure that API, as long as there is parseable log available.
All things being equal, the API limits what can be done on the server. A shell can be restricted too, but there are evasion techniques possible.
There may be plenty of reasons why they have that API, for example automation. But they could probably use Ansible (over SSH) as well.
Of course the API could have vulnerabilities too, like SQL injections, introspection attacks, you name it. APIs have been abused to exfiltrate data. Facebook, Twitter etc are testimony to that. So it could actually be an attack vector that makes the server less secure if it has severe design flaws (and there is no such thing as bug-free software). Whereas SSH is a mature protocol but the devil is in the implementation. Whatever you choose, you should always strive to reduce the attack surface so you have to protect the other layers as well and secure your perimeter.
Remaining points to consider: logging, auditing, alerting...