One can certainly make that argument. But now you have two ways to run executables; via the shell / fork - and through the init system (with various capabilities etc).
I guess I'd prefer a single api, so I could sandbox (or not) netcat and Firefox the same way as samba and openssh.
It might not be a major point - but it would be nice if there was a single way to "run in env/with configuration" that didn't involve an extra (and somewhat opinionated and opaque) wrapper.
It's a little like the dot.desktop-file approach to dress up cli tools/interfaces in a desktop gui - it's brittle and doesn't really work all that well. And the cross-platform story isn't great.
On the other hand: attaching capabilities to process trees seems better that text-based matching etc. I suppose I think the bsd jail approach looks better - even though that to involves a "wrapper" - but it's a wrapper that's not artificially limited to "services".
[ed: the fact that any kind of name lookup is left out is also a bit odd - as demonstrated by the curl example, for many uses of whitelisting name resolution is essential. And for ldap/kerberos/ad being able to work with named resources seems to be the only sane idea. That's why we use dns and catalog services in the first place! This even more clear in an ipv6 environment, as the addresses are generally longer, and auto-assignment is somewhat better than ipv6/DHCP.]