It's not enough that a system has the capability to do something; Ideally it needs to be well documented, easy to use correctly, difficult to use incorrectly, repeatable, and have it's correct usage verifiable. With logging and monitoring available.
When you have a piece of software you want to sandbox.. how exactly are you going to do it? What are the steps? Are they going to be easy for other people to follow and understand what is going on? How do you know it's working correctly?
These sorts of things matter. Not just in terms of usability, but also security. Having the same limitations and kernel hooks underneath doesn't make sandboxing implementations identical. it's still very much possible to have one that is objectively better then another.
I don't know if this is the best implementation, but it's certainly nice that if you are using Linux you probably have it available already. Out of the box.
You're correct at a very narrow level considering only the mechanism used to apply the sandbox but think of the larger picture and especially how container runtimes are not created equal. For example, dockerd involves a running daemon with access control issues which many people handle by handing out root access. podman is better but far less common outside of the Kubernetes world. If you're trying to give generic advice, systemd avoids needing to drag in that extra discussion about which launcher you're using and how it's configured.
An interesting question would be integration with other features like SELinux or seccomp, since those are commonly punted on but make a huge difference in security.
