I think the part in the docs about a component being potentially activated and deactivated many times during its lifetime refers to the fact that an entity can be repeatedly activated/deactivated (which will activate/deactivate all the individual components on the entity), so when writing the activation code for a component you should be careful to make sure that it can be reactivated safely.
It is a bit awkward to deactivate individual components, because other components may depend on them, and they would have to be deactivated as well. This could lead to a whole chain of deactivations which might have unintended consequences. It is also not a totally trivial operation to evaluate the dependency graph and deactivate the necessary components to return the entity to a valid state. For this reason, the system is not really designed to modify the components of an activated entity at runtime. Even the destroy component node which you mentioned will only work on a deactivated entity.
The suggestion you made of putting the component you want to deactivate on a child entity sounds like it could be a reasonable approach. Could you give a little more detail about your particular use case?