The OBJECT-GROUP macro is, as you state, used to group conceptually related managed OBJECT-TYPES located at various OIDs. However, they do not have to be from the same subtree. The OBJECT-GROUP macros are not, strictly speaking, required as the fact that it is only a level 4 warning from smilint will attest.
The answer you linked to does mention some of this, but hopefully this is a more useful answer for you.
As to the purpose of these things, I will attempt to explain. These OBJECT-GROUP and MODULE-COMPLIANCE macros are intended for those that will implement the MIB you are creating, rather than for anything to do with the MIB itself. The OBJECT-GROUPs give an idea about the logical relationships of the OIDs and the MODULE-COMPLIANCE statement shows which OIDs are mandatory under what circumstances. i.e from RFC2580:
The compliance statement contained in the (hypothetical) XYZv2-MIB
might be:
xyzMIBCompliance MODULE-COMPLIANCE
DESCRIPTION
"The compliance statement for XYZv2 entities which
implement the XYZv2 MIB."
MODULE -- compliance to the containing MIB module
MANDATORY-GROUPS { xyzSystemGroup,
xyzStatsGroup, xyzTrapGroup,
xyzSetGroup,
xyzBasicNotificationsGroup }
GROUP xyzV1Group
DESCRIPTION
"The xyzV1 group is mandatory only for those
XYZv2 entities which also implement XYZv1."
::= { xyzMIBCompliances 1 }
According to this invocation, to claim alignment with the compliance
statement named
{ xyzMIBCompliances 1 }
a system must implement the XYZv2-MIB's xyzSystemGroup,
xyzStatsGroup, xyzTrapGroup, and xyzSetGroup object conformance
groups, as well as the xyzBasicNotificationsGroup notifications
group. Furthermore, if the XYZv2 entity also implements XYZv1, then
it must also support the XYZv1Group group, if compliance is to be
claimed.
So, as stated in the other question if you do decide to create OBJECT-GROUP macros, you should probably then follow through and also create the supporting MODULE-COMPLIANCE objects to go with them since you've already gone to the trouble.
