It seems that for some of the APIs, the main reason to remove them is to allow us to change the internals – to add new features, optimizations, or simplifications.
IMO, that’s a good reason to remove them at the time when we need to make the change.
I don’t think pre-emptively deprecating these, with a removal date set a few releases in the future, works well. If the internals need to be changed sooner, we’re either blocked or break the API before the documented time. If we don’t get around to changing the internals, but remove the API anyway, we break users without a good reason.
Would it be better to mark them as deprecated, but without a planned removal date? Then, they can be removed when necessary. (Like any private API, of course – but with a warning and with porting notes. Good porting notes in particular should help to ensure that it’s possible to switch to supported APIs, and make the switch as painless as possible.)