You're not testing the enum case: that is to say, the enum case is neither the argument of a function call nor the receiver, neither the LHS of an operator nor the RHS. You are testing a substitute for the enum case; namely, the synthesized property. There is no use of the enum case per se which is affected by your proposal.
Again, as of SE-0155, enums with no associated values are not equivalent to enums with an associated value of Void, and both should eventually be able to co-exist in the same enum type. Swift, for better or worse, has completed the distinction between the lack of a value and the presence of a value Void. The payload of a type with no associated value isn't of type Void (or rather, won't be in a short while), as an analogy to your examples here would suggest. It's of no type at all and cannot be expressed in Swift.
Would you omit the keypath to a property of type Never? I'd say there's a good case for doing so. (Yes, imperfect analogy, as the payload of a case without an associated type cannot be said to be of type Never, either.)
Of course it's a valid argument. No aim of your proposal is "completing key paths"; we have no need to aim closer to completeness for its own sake. As I said, I would have no problem if it were impossible to write keypaths for struct properties of type Never, and I see no issue with enum cases without associated values being treated similarly. (Besides, can you even write a keypath for a statically absent member of a @dynamicMemberLookup type? Would you think it's a huge problem if you can't?)
Swift has always reserved compiler synthesis and other conveniences for only the most obvious situations. Some enums are magically Equatable and others are not. Some custom types can have synthesized Codable conformance and others cannot. Some standard library types have conditional Hashable conformances and others do not. It's entirely consistent with the direction of Swift to omit "edge cases" for synthesis.