I'm a little bit worried that this is getting into specifics of one Nullable annotation vs another; I know they aren't all equivalent and there were limitations lifted with later annotations. Given that everything is @Nullable, we know this annotation has no behavior right now, which means verifying behavior is out of the question.

I was trying to use this type in our code, with the result of unexpected warnings from IDE

There are plenty of such warnings in this repo as well, e.g.

getValue() is nullable, so result can be null, and then there is a warning for result.addresses

All arguments/return types in gRPC should be Nullable from a tool's perspective. We don't have NonNull enabled at the package level. To my current understanding, if these changes here are causing changes in the IDE, then the IDE is broken.

From a tool's perspective - default nullability is unknown.
However ,getValue() is explicitly annotated as @Nullable, that makes the result local variable also nullable. There are no null checks in this code, so the tool issues a warning about possible NPE. That's the whole point of using @Nullable. The tool (IDE) works correctly.

Why getValue() is @Nullable?

The suggested approach doesn't actually work with javax.annotation.Nullable:

   grpc-java/api/src/main/java/io/grpc/StatusOr.java:69: error: annotation @Nullable not applicable in this type context
    private static final StatusOr<@Nullable Object> TESTING = null;

But the @Nullable isn't actually providing any value (as it doesn't actually restrict whether the method can return null, as no method is annotated non-null), so if it is causing problem we can remove it for now.

The suggested approach doesn't actually work with javax.annotation.Nullable

Correct, should be newer annotations, e.g. jspecify.