- First of all quote from RFC3411
For example, the managed object type ifDescr [RFC2863], is defined as
the description of a network interface. To identify the description
of device-X's first network interface, four pieces of information are
needed: the snmpEngineID of the SNMP entity which provides access to
the management information at device-X, the contextName (device-X),
the managed object type (ifDescr), and the instance ("1").
Each context has (at least) one unique identification within the
management domain. The same item of management information can exist
in multiple contexts. An item of management information may have
multiple unique identifications. This occurs when an item of
management information exists in multiple contexts, and this also
occurs when a context has multiple unique identifications.
The combination of a contextEngineID and a contextName unambiguously
identifies a context within an administrative domain; note that there
may be multiple unique combinations of contextEngineID and
contextName that unambiguously identify the same context.
- Usecases
The OSPF MIB defined by the IETF (RFC 1850) was designed to work with only one OSPF process/instance on a given router.
For example, there is only a single ospfRouterId object, not a table of them. In order to handle multiple instances, RFC 4750 suggests that you use SNMPv3 contexts to provide per-instance views.
Link Manage Multiple Instances of OSPF with SNMP Contexts
This KB provide solution on how to poll information from a SNMP v3 server which is located in a non-default routing-instance
Link How to pull SNMP v3 information from non-default routing-instance Juniper
So there is lot of cases when you may use snmp contexts: security, separate logical entities on one physical, etc.