The code here is somewhat contrived in favour of the ints. Taking the meat of the | example…

    int a = A | B | G;
    for (int i = 0; i < 1_000_000_000; i++) {
        int b = A | B | G;
        assert a == b;
    }

This is actually compiled as

    int a = 67;
    for (int i = 0; i < 1_000_000_000; i++) {
        int b = 67;
        assert a == b;
    }

The compiler should trivially identify that a == b is always true.

This simple change to the Enum case brings it to within 3x the int scenario…

    Set<Flag> a = EnumSet.of(Flag.A, Flag.B, Flag.G);
    Set<Flag> b = EnumSet.of(Flag.A, Flag.B, Flag.G);
    for (int i = 0; i < 1_000_000_000; i++) {
        assert a.equals(b);
    }

A better range of benchmark cases is required.

Interesting analysis, but the conclusion is a bit contrived. People often prefer type safety over performance. When it doesn’t impact type safety, they still prefer better performance over worse performance. That’s not a contradiction.

You could argue that introducing the EnumSet-type isn’t worth it for that, but I don’t really see a disadvantage from having it.
Those who know about EnumSet, can use it. Those who don’t know it, can continue to use HashSet. And if you don’t know about EnumSet, but find one in a code base, it’s not hard to guess what it does…