The reason for "disabling root" and using sudo with a regular account instead has multiple purposes, none of which affect the answer to your question.
System software is always installed as root. Sometimes application software is installed as an application specific user, but typically not. Disabling login for the root account doesn't change this, and it doesn't change how applications are started at boot.
The point of disabling the root account is so that you log in as a normal user and do user session like things as a normal user and not root. Then you use sudo to elevate to root to install software and do other dangerous things. This also has the side effect that when you use sudo, the user account that did this is also logged, which is not that interesting unless there are multiple user accounts that can use sudo, in which case, it is easier to assign blame when a mistake is made. So installing software is still done as root -- just via sudo instead of direct login.
When an application (like NginX, mysql, mogodb, etc.) is configured to start at boot, typically the systemd (or initd) boot scripts start the application as a special application user. This user is created when the application is installed. You should not be starting the application by hand, but allowing the installed system scripts to start it (for instance with systemctl start ...) so that it runs with the correct permissions in the correct environment. The design philosophy behind this is that the application is isolated within its own user, and security issues with the application will (hopefully) be trapped in that user id. Most applications should not be run as root directly.
Having said all this, on a system with a single administrator, logging who uses sudo is less interesting, and if you have cloud images that you can just zap and reload from a fresh copy, what user you run things as inside the container is also less important. This is probably why your cloud image comes with root enabled and no separate administrative user.