I fail to see how this is anything but the perfect case for allowing internal API usage.
There was no other way to do what Unsafe did, so people used it for years.
A lot of people used it to do useful things in Java. So much stuff that this article is saying it literally became indispensable for much of what Java is used for. The ecosystem was better for it.
Sun says we want to remove it.
So Sun can provide alternatives that do the same job, or find that it generates so much value that it shouldn't be removed, or remove it and leave people literally exactly where they'd be if it never existed if there's no other way to do what it does. People would gnash their teeth, but the message sent is "Java was never the right tool for the job so we don't want you as a user."
And the article rightly points out, Sun was removing it for the sake of removing it. Having a bad engineering structure where that handwavy rant about Unsafe can justify removing a useful feature has nothing to do with internal vs public APIs.
The usage of Unsafe was never encouraged, it is a problem that Sun never provided a public API with similar features but relying on a private API is what caused the issue of breaking changes in the future, something that every Java developer was well aware that could happen.
Yes, I agree that the problem was that Sun didn't provide a public API for it, at the same time developers breaking the contract (instead of pushing for it to be moved to a `java.` namespace) shouldn't be excused and embraced, it causes bigger issues to the overall design of the platform when then you have to be maintaining an API for the sake of usage, the same cruft that Win32 suffers for its whole existence, and which made developing on Win32 a pain in the ass for a lot of people, for the sake of not breaking some twisted way that a major application used it.
[0] https://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disas...