I think the answer depends on your goals and priorities.
If you are planning on having very large deployments, or need a system with multiple frontends having the database on a separate server allows you to split the load and can provide better performance overall with better scalability. Likewise if the database server is only reachable on a LAN and not directly from the Internet it is that much harder to compromise.
On the flip side, if you have powerful servers and are trying to get the absolute best performance, hosting SQL on the same VM is likely to be faster because you don't have the network IO to contend with.
In practice, most small sites would have the database on the same host as the webserver, while large deployments will have dedicated database servers - generally with the infrastructure designed to maximise performance for the environment.
Moving SSH to a port other then 22 is, IMHO, a waste of effort. If you care about security, locking down SSH to only allowed IP addresses using a firewall (and using a VPN to overcome the limitations of dynamic IP's and allowing an additional layer of security) is a way better best practice. More importantly though if you are running an SQL database you should ensure it is not reachable from the wider Internet. This can typically be done by only allowing access from the loopback interface or 127.0.0.1. For added security, firewall off port 3306 (for MySQL) or 5432 (for Postgres) - this will offer most of the security of having it on a separate box which is not available on the Internet.