After some further investigation, I don't think we can fix this in Entities 1.x without breaking API changes. At the point where WithNone<T> is specified and system type dependencies are added, we simply can't tell whether the user's intent is that the type is missing (in which case, no type dependency should be added) or disabled (in which case, a read or read/write dependency is necessary). I've filed a ticket to revisit EntityQuery type categories to avoid this ambiguity.
The workaround in the meantime is to prefer the WithAbsent<T> or WithDisabled<T> alternatives to WithNone<T>, which let you more explicitly declare a query's expectations around an excluded component type. Specifically, if a system will be re-enabling disabled types in a job; it should use WithDisabled<T> instead of WithNone<T>. It seems uncommon that a query would genuinely not care whether a type was absent or disabled, but in that case (if the type is actually not accessed at all) then WithNone<T> would be appropriate.