Post Scriptum: It's obvious that the example does not show a good style of programming. I exemplified a situation that happened to me during a refactoring, in which certain edge situations like this can occur.
Here is a simple test that might be related to the issue, see below. There are no classes involved, but a (record) type that is defined in an other unit (unit uTypes). The type is the result of a function implemented in Unit1. Obviously uTypes needs to be added to "uses" in that unit. Unit2 uses the function of unit1 and can access the result type even if uTypes is not added to "uses", see the code of unit2, especially the comments. I think its useful.
I'd suggest that there's a big difference between "needs to be added to 'uses'" and "is automatically made public" which is what OP was demonstrating.
.... I don't see that the OP demonstarted that the type itself was automatically made public[1], but only that the enum identifiers were made public. And I see the enum identifiers similar to the record member identifiers.
Then it seems these identifiers are automatically made available by the compiler if the type is used as parameter. And "making it available" in the one case is like making it public and in the other case like beeing added to uses.
Why are the values of TMyEnum visible outside the module, even though they have been declared as (strict) private in the class they belong to?