How much safer is running containers as a non-root user?

It reduces what the application can do if it gets compromised. A non-root process generally has fewer privileges inside the container and can only modify mounted files that its user or groups are allowed to write. A read-only mount is even better for data the application never needs to change.

That does not make the container a complete security boundary. The process still has access to whatever you give it, including writable volumes, network access and any credentials available inside it. If a sensitive directory is writable by that user, running as non-root will not protect it.

Root in a container and root on the host depend on how user namespaces are configured. Without user namespace remapping, container UID 0 normally maps to host UID 0. The process is still subject to container restrictions, so that is not quite the same as an unrestricted host root process.

With user namespace remapping, container root maps to an unprivileged host UID. That adds a useful layer, but check volume ownership and permissions before enabling it on an existing setup. Host files may need ownership or access changes for the remapped users.

Take a look at the processes from the host with a command such as ps -ef. Container processes are host processes too, and this can help you see which host user they run as. Check the numeric UID and group IDs if names are confusing, especially when user namespace mapping is involved.