The risk is that when the standard library adds the conformance, the programmer is long gone. Dave wrote his application, it's shipped, and two years later Apple ships an update to the OS that adds the conformance. Now we run directly into the problems outlined in Retroactive Conformances vs. Swift-in-the-OS. The programmer today wants the conformance, but they're long gone and their app is busted. As is well documented in the annals of computing history, users will rightly blame the last thing that moved: after all, the app worked before and now it doesn't, and the app sure as hell didn't change.
Another constituency you're missing here is library authors. Library authors absolutely must not add retroactive conformances because, again, they're often not able to fix the problems those retroactive conformances cause. Many libraries become essentially unmaintained, or you are forced by other circumstances to use older versions of them. In this instance, the user of the library may not even have known the retroactive conformance was there, but now it's their problem, and they have the unpalatable choice of either forking the library or removing its use.
Put another way, the issue with retroactive conformances is that they fix today's problem by signing up for a future problem, one which will strike without warning and likely fall on a very different person than the one who benefited from the fix.
This analogy isn't the point, but: in this analogy, the issue is that "would be destroyed" is in the passive voice. A better one would be:
"This ravine might eventually get filled in by a public-works project years from now, at which time we will be unaware that you have built a bridge and so will knock it down by accident in an uncontrolled fashion, potentially causing it to fall on whatever lies beneath it. We will be liable for that destruction, not you, and so we would really much rather you didn't build the bridge and certainly have no intention to make it easier for you."
This, however, I agree with. I agree with @lorentey that exposing _base because we want to use it to implement retroactive conformances is a bad idea. But I think exposing it is a good idea: it enables entire classes of algorithms that are otherwise awkward to implement, it costs very little in flexibility of evolution because the types are frozen anyway, and ultimately I have a "consenting adults" view of API design. But I definitely understand why the stdlib devs are hesitant to expose this implementation detail, and if this were the problem I had I would absolutely just copy the implementation myself and move on.