This depends on what the user can do with the SSH access. If he is limited to specific actions like scp/sftp, selected port forwarding or running selected commands the risk might be small. If instead the user has full shell access then he can use local privilege escalation attacks to elevate his privileges from a normal user to system user. Bugs which allow such attacks get regularly detected and some of these lurk for many years without getting publicly known and fixed.
Apart from such direct privilege escalations a user with shell access can also connect to network services which are explicitly restricted from outside access and might not be that well protected because of the risk is considered low. This might for example be local database installations with insecure and easily brute-forced passwords. And apart from the local systems the user might get access to internal systems on the same network which are usually protected from the outside using a firewall.
And of course a user with a login shell could just exhaust system resources like memory, CPU time, I/O or disk space unless specific limits are set on the account.
These are just the more obvious problems. But note that most of these could also already be done from inside a PHP script or similar server side code in control of the user.
In summary: if there are sensitive data on the system or on connected and reachable systems don't provide a way for an untrusted user to execute arbitrary code as a non-privileged user. This involves shell access but might also already involve using its own PHP scripts or similar. If such code execution is needed you can try to mitigate the risk by adding additional security layers, like sandboxes, containers or similar but note that these restrictions are not unbreakable either.
