I don’t know if there are problems with this tool, but the App Sandbox is very configurable and every app store app is in one. It doesn’t make sense to maintain two different complex sandboxing solutions.

App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.

By far the biggest advantage of App Sandbox is that the policy ships along with the OS. If a system framework changes what resources it accesses in a software update, Apple can update the policy so the framework functionality still works. If your app uses a custom sandbox policy, you're on your own to both notice that something has changed and to update your policy.

The downside is that the App Sandbox policy is limiting and inflexible.

That’s not true. Lots of apple’s own first party apps use SBPL to sandbox because the entitlement granularity doesn’t cut it. There’s also lots of apps on the MAS which use temporary-exception SBPL to fully sandbox.

I agree that there is no sense in operating dual systems, but entitlements can’t replace SBPL yet.

If swift package manager is using it (I believe it is based on some of the error messages I occasionally see from it), deprecating it is difficult, since SPM is not distributed as an App Store app.