The phrase explicit state comes up in discussions about component architecture. I find this an abstract concept, I'm guessing that it means there is a state object I can store/interrogate that contains the complete component state.
Forgiving for a moment the assumption that the state of the object is one thing (I suggest state is dependent on context), then it's true the DOM does not provide information in this format. It's also true that Web Components does not have anything to say on this point.
It's understandable that vendors of tools that want to consume state in this way would be happier if all DOM elements (and transitively all Custom Elements) produced such an object. Otherwise, there is an impedance mismatch with their particular flavor of application design.
IMO, there is a very similar issue with respect to dependency injection, where proponents want their particular inflection baked into the lowest level possible so they have maximum interoperability.
Again, such desires are understandable, but presuppose that the various opinions are objectively correct, and any variation from those methods are inherently failures. This is contrary to the notion of primitives; a primitive allows for multiple ways to utilize a base system, admittedly with potential costs for impedence matching.
Interoperability is fundamentally good. Polymer encourages interoperability by presenting objects as the de facto lingua franca, HTMLElement.
Therefore, the various schools of thought that suggest this is not enough are unhappy with the core capabilities of HTMLElement. Some feel that data binding should be baked in (and we are tantalizing them with Node.bind). As mentioned, others want state management, dependency injection, and so on.
It's an explicit goal of Web Components to allow developers to explore these various options, in such a way that real experience will determine if a feature is so universally applicable that it should be baked in to the platform. Therefore, there is an avenue for proponents of these features to provide them, and evangelize their opinions with real code. If the systems they advocate prove themselves, they will eventually become standardized.
To my understanding, none of the mentioned technologies are so obviously good that they can forgo this process and go straight to standardization.