This seems redundant. The JDK already warns about this. Do we need duplicate warnings?

Thanks for the PR!

If a project doesn't pay attention to javac warnings, they are unlikely to pay attention to pmd warnings. I think not duplicating existing JDK warnings should be a hard line.

I can see, that such a rule might be useful in reviewing an existing library. Even if the authors of the library don't use PMD or ignore PMD warnings (in addition to javac warnings), you as a user could use PMD to check the library, that it fits your expectations.
So, the users of a PMD rule are not always the authors of the code that is being checked.

This seems redundant. The JDK already warns about this. Do we need duplicate warnings?

Having this rule in PMD doesn't force anyone to use it. It's still up to the developer to enable the rule.

As a library author, I maybe won't need this rule, as javac issues a warning anyway (apparently since 2006 / 19 years).
With JEP471, most methods are now deprecated, so an additional warning should be issued by javac when using Unsafe now.
With JEP498 the warning is now also shown at runtime, e.g. when you execute an application that uses a dependency, that uses Unsafe.

I'd suggest the following changes:

• move this rule to category error prone. I think, that is a better fit than security. If you use unsafe, you provoke undefined behavior including JVM crashes.
• the rule has a similar motivation as DontImportSun. That rule only checks for imports, as at the time, the rule was implemented, that was the easiest way. "These packages are not portable and are likely to change." It sounds similar as in JEP 471 "...not exposed as a standard API". This is expressed in the fact, these classes have been moved into the module "jdk.unsupported" - if you use anything from this module, your application/library might fall apart with any future java version, as you are using an unsupported API.
• Therefore I'd suggest to name the rule "UnsupportedJdkApiUsage" and subsume both the import aspect and unsafe usage under this new rule. The new rule should then also find module-require-statements for "jdk.unsupported". But in general, any usage of all packages of "jdk.unsupported" should be reported and not just sun.misc.Unsafe. And it could be extended to detect many more packages, that happen to be on the classpath and available, basically anything like "jdk.internal" (including jdk.internal.misc.Unsafe).