This question may be better suited to https://security.stackexchange.com/ as the idea and implications are not at all specific to SQL Server, they apply to any other internal service.
Changing the SQL Server instance port generally adds very little to security - it is a "theatre" action rather than a real security benefit, something to put on a checklist to make it look like you are doing lots for a security-in-depth policy. If the browser service is still open anyone getting in can ask that what port SQL is listening on. Multiple instances of SQL on different ports is not uncommon so automated attacks against SQL Server will generally scan for instances on other ports if one is not found on 1433, while an attack could take some tens of seconds longer an automated attack bot has all the time in the world to wait.
If the outside world can see port 1433 then that is the problem (your firewall/other setup is too open) and changing ports probably won't fix that because the new port will likely be open to the world too. If an attacker is inside you infrastructure so can see the SQL Server listening port for that reason then you have a significant security problem elsewhere that moving SQL's port also won't help with.
 NOTE: I don't mean to imply that security in depth is a bad thing, it very much isn't. Security in depth should be a core goal of all environments. But try to avoid security theatre which adds hassle but not actually any real security benefit when you could be spending your time doing something else that actually does improve security.