In that case, sandboxing could never be introduced. It is quite literally impossible to provide entitlements for any and all functionality under the sun, unless you include the entitlement "allow anything" in the mix. Sandboxing is by its very nature restrictive, requiring bits of functionality to be whitelisted. That's the only way in which it can possibly ever be even remotely secure.
However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are. If you cannot ship your app with the sandbox, then you can continue to be distributed the way all apps were for the past few decades.
> Part of the problem is that a lot of things pose no security threats but there are still no way to access that functionality in a sandboxed app - that's the crux of the problem.
Can you give examples? I do not blindly accept that GaragePay's use of `hdiutil` is harmless, like you are claiming. `hdiutil` is not sandboxed, and I have no idea what kind of security audit, if any, has been done on it to see if there's any security vulnerabilities that would be exposed by allowing it to be run from a sandboxed application.
> The correct way to have resolved this was to expose APIs to access that functionality
Yes, APIs that allow for manipulation of disk images would be nice. But that's not even remotely a trivial task.
> In almost all cases, the functionality can be sandboxed if Apple provided an API to access it securely
That's practically tautological. "The functionality can be sandboxed if Apple allowed it to be sandboxed". Some missing entitlements would be trivial to add. Others would require massive work. I suspect that exposing proper APIs to manipulate the Disk Images infrastructure would require a massive security audit, and probably significant work modifying the APIs as well as I expect they probably don't meet the usability standard expected of public API.
> removing functionality objectively leads to an inferior experience due to the lack of said features
And implied that this means Apple should allow third-party apps to continue violating rules because the existing experience of using that 3rd-party application somehow trumps everything else.
Beyond that, I don't necessarily agree that this does objectively lead to an inferior experience as well. Removing insecure functionality, or functionality that relies on non-public APIs, can lead to a superior experience, because the application is now more trustworthy, much less vulnerable to exploitation, and perhaps more stable or future-proof (in the case of non-public API). So it really can be quite subjective, and quite dependent upon the particular merits of the functionality in question.
> The root issue is that if the required entitlements were available, then the app wouldn't be violating any rules at all and we wouldn't even be having this conversation.
Again, tautological. "If the app wasn't violating any rules, it wouldn't be violating any rules".