Like those two, DynObj prevents copy and assignment since they don't "fit" with the role of the class. The technique used by NoPtr is to allow DynObj a "controlled" form of copy and assignment within an STL container. This is allowed only when specifying DynObj<TT>::InValueContainer as the element type for DynObj when it will be used inside a value-based container. It is controlled in the sense that it is limited to the uses, by the STL containers themselves, that really require it, such as insertion into the container, and re-ordering of the container.
You may think that, DynObj<TT>::InValueContainer being a version of DynObj<TT> that allows copy and assignment, it is in essence shared ownership. However, DynObj<TT>::InValueContainer does NOT provide shared ownership. Remember that DynObj<TT>::InValueContainer is, from your point of view, identical to DynObj<TT>. The ::InValueContainer is necessary only because C++ does not currently provide any method of doing this without user (i.e. your) intervention. Any attempt, intended or not, to use the item inside a container of DynObj as a shared ownership smart reference will several assertions to fail at run-time.