Really? You don't get why apple would want to avoid software unexpectedly breaking on every OS update (on user devices, to widespread cries of "Apple broke software X") because the dev used an undocumented and unsupported private API which was modified or removed entirely?
No, the situation posted about is one where developers get their application rejected, nothing is broken.
> Why do they want things to break now rather than in some hypothetical future?
1. breakage in private APIs is absolutely not hypothetical
2. rejecting submission is a very different (and much milder) issue than applications breaking on end-user systems
In contrast, if they continued to use private APIs then the app's future failure point becomes entirely unpredictable. The entire point of private vs public isn't security or arbitrary conformance or whatever per se, but rather flexibility. Apple wants to be able to alter internal implementation details as their needs dictate, or feels that a given API is not yet one they're comfortable committing to maintaining intact long term. That means it may get changed not merely in a major OS update but even in a maintenance update. What if everything breaks in iOS 11.2.3 a couple of years from now? Will all of these apps actually still be maintained? Will their developers even still be in business at all? Users would have zero warning, it wouldn't even necessarily happen on a major update where incompatibilities might be more expected.
ObjC (and other dynamic languages) cannot enforce "private" in code, and on OS X there is a long history of private API use, which probably is part of what drove Apple's decisions here. I've used private APIs there myself, at times in the history of its development it's been the only way to accomplish some really cool stuff. But it was absolutely fragile and also resulted in a lot of things that'd break later if not actively maintained, either when Apple removed it entirely or conversely stabilized it and baked it into public APIs/frameworks.
Apple wants to be able to maintain an aggressive OS upgrade schedule and simultaneously have apps continue to work even if they're from many versions back and are no longer actively maintained (which is an important part of getting most people to upgrade). Requiring App Store software to stick to public APIs is one reasonable way to work toward those goals given their constraints.
FWIW there may not be a public API for what they're trying to do.
> ObjC (and other dynamic languages) cannot enforce "private" in code
Even if they could, a root issue here is that it's a UI views tree (so it's possible to access any subview by traversing the views tree), to fix that you'd need to wrap any non-public view object in some sort of opaque view adapter/proxy to prevent anyone getting a handle on them, which would be hard to enforce and would have a runtime cost. Once you've got a handle on it, unless the language has neither reflection nor unsafe observation (e.g. digging through the vtable directly) your private API is toast.
Unfortunately, that's part of the nature of working within Apple's ecosystem---you want store support, you play by their rules. Their rules don't allow your app to exist, you sit on your hands and wait 'til they do. The benefit gained is a bit of consistency of experience on the user's side.
Of course, I didn't say they'd still be able to accomplish the same thing, after all that's the most common reason one would be interested in using private APIs in the first place. On Mac OS X (as it was back then rather then "OS X") for example at one point there was no good public API for menu bar extras. Apple wanted everyone to use the NSStatusBar API but it was vastly less capable then the private version Apple used, so naturally the latter was rapidly reverse engineered and a whole ecosystem quickly developed. There was actually a bit of an arms race for a while, a preface perhaps to the current iOS situation, because with Jaguar (10.2) Apple added new code specifically to attempt to force the exclusion of all 3rd party menu extras. Apple wised up about that later and just accepted that a bleeding edge would exist, but they were pretty sensitive even very early on to worries that crashing or bugs in 3rd party software that took down soemthing major (like the entire SystemUIServer) would have a major negative effect on perception and adoption of Mac OS X on the whole. Presumably at least some that attitude in turn dates all the way back to the stability horror story that was classic Mac OS in the later years in particular.
On the Mac it was futile and pissed off devs and power users, the block was broken before Jaguar was even GM'd, but it's something they've clearly never entirely forgotten and now under iOS they're using their control to enforce it. Even if functionality is only possible with a private API in the present OS release they'd rather an app be forced to use less but be more sure that it'll work at all in the long term.
Apple would rather not be shackled to popular developers cracking open their design to do things that are forwards-incompatible.