Is permits keyword used in other context aside a sealed class or interface?

In context of a sealed type (JEP 409), it does not make sense (please give examples of real use-cases scenarios if otherwise) to declare a sealed class or interface without mentioning the classes or interfaces that are permitted to extend them.

Logically speaking, to beneift entirely from this new feature as it was intended, you are bound to mention the sealed and permits keywords together.

My main question (and sub-sequent questions based on answer provided to main question) then would be:

Are sealed and permits keywords used in other context than by using them together to achieve sealed types?
1. If no, why permits keyword, when designing this feature, was not enough to be determined by the compiler that it deals with a class or interface that should not be extended or implemented by another class or interface? Why the need to explicitly mention the sealed keyword? Is it something that helps the compiler be more efficient because sealed keyword arrises first, and based on compilation algorithm it makes sense to filter the classes that are having the sealed keyword such that it adapts the flow of compilation in such a way to not deal with extra steps since it is sealed?
2. If yes, which are those? Please give examples that actually bring a benefit, excluding the obvious part where compiler can deal with classes or interfaces that can have just sealed keyword on them without permits being present (which doesn't make sense, from my knowledge).

I tried to compile types marked as sealed but without mentioning permits and it works, but I couldn't find the actual benefit of it.

Not challenging the way the feature was designed, just trying to understand the reasoning behind it, since I could not find a use-case where sealed makes sense or is recommended to be used without permits keyword.

Solution

permits is only one way to say what subclasses are permitted. Quoting JEP 409,

When the permitted subclasses are small in size and number, it may be convenient to declare them in the same source file as the sealed class. When they are declared in this way, the sealed class may omit the permits clause and the Java compiler will infer the permitted subclasses from the declarations in the source file. (The subclasses may be auxiliary or nested classes.) For example, if the following code is found in Root.java then the sealed class Root is inferred to have three permitted subclasses:
abstract sealed class Root { ... 
    final class A extends Root { ... }
    final class B extends Root { ... }
    final class C extends Root { ... }
}

Root is automatically inferred to permit A, B, and C.

Having a keyword for sealed allows more flexibility in the language design for permitted subclasses, and makes it easier to tell at a glance if a class is sealed.

Whether sealed or permits are used in any other contexts isn't really relevant. (I don't think they are, although they might be in future language versions.) Other uses of sealed or permits wouldn't affect the design of this part of the language.