It's more secure because you're minimizing the attack surface. The jailed process has no binaries an attacker can use to further exploit the system, not even a shell. It means that there's a minimal to non-existent /etc directory, meaning there is less information about the server and the network it's on. It also means there are fewer places to hide modules to persist, because you control so much of the tree.

Going further, you can place the few executable files you need in a read-only filesystem, so attackers can't copy their own payloads in, further restricting what they can do. You can continue that process with firewall rules that are much more restrictive than what you could use with a more general purpose server, such as blocking any traffic that isn't to or from port 80/443. You can also virtualize the network of a jail, so an attacker wouldn't even get information about the network's layout from a compromised jail.

Heard the same about SELinux.

Typical application attack path:

RCE in the app -> ability to use anything in the OS under the app user privileges -> privilege escalation -> The whole box pwned (including access to all your secrets and management credentials)

Remediation process: wipe the box

Attack path for an app within a jail:

RCE in the app -> ability to use anything in the OS but there is nothing to use, must bring own tools (not always feasible) -> privilege escalation -> JAIL is pwned but not the box

Remediation process: recreate the jail

The complete mess that is containers on linux seems a whole lot more complicated to me. Jails do what you want in a simple way that works; containers are endlessly customizable such that you require a whole runtime and management daemon and message-bus integration and goodness knows what else.