In the past we used the TOGAF module with the full dedicated TOGAF MetaModel (TOGAF-pure setting in the options). This implements dedicated physical MetaClasses for concepts like Logical & Physical Application Component, or Logical & Physical Technology Component. Since we were also using other modules like Process BPMN, we had to make some extensions to the MetaModel to ensure the TOGAF, BPMN, and other native HOPEX MetaModel aspects were integrated. When we moved from MEGA 2009 to HOPEX 2 years ago, we decided to stop using the dedicated TOGAF MetaModel, since it wasn't being integrated with the new HOPEX offerings like ITPM, and we would consequently have to constantly maintain an extended MetaModel to be use to those new offerings. We also changed our methodology a bit to reduce the number of diagrams/reports that had to be created/.
My understanding is that the non "TOGAF-pure" implementation uses abstract MetaClasses to represent TOGAF-specific concepts like Physical Application Component, and uses HOPEX native MetaClasses as sub-types (ex.: Application is a sub-type of Physical Application Component). In that way it may be easier to integrate with the other HOPEX offerings like ITPM, since you would be using native HOPEX MetaClasses.