Thanks for providing the WKT representations, quite helpful.
A quick, or not so quick, aside before moving on. When talking about valid geometries and spatial relationships, the nuance and complexity of the topics are often lost or oversimplified in conversation. There are very specific definitions, and sometimes there are disagreements or discrepancies between different groups/companies/organizations when it comes to the meaning and implementation of those definitions.
Looking at the examples provided in the context of ArcPy Geometry classes:
>>> #OBJECTID 1
>>> l1 = arcpy.FromWKT('MULTILINESTRING((9700614.7831249982 4432945.8557500001,'
... '9700614.7831249982 4427945.8557500001,'
... '9700614.7831249982 4428945.8557500001))')
...
>>> l1.overlaps(l1)
False
>>> l1.crosses(l1)
False
>>> l1.touches(l1)
False
>>>
>>> #OBJECTID 2
>>> l2 = arcpy.FromWKT('MULTILINESTRING((9702086.5310000032 4431846.6370000001,'
... '9702086.5308749974 4428846.6367499996,'
... '9702086.5308749974 4428846.6367499996))')
...
>>> l2.overlaps(l2)
False
>>> l2.crosses(l2)
False
>>> l2.touches(l2)
False
>>>
>>> #OBJECTID 3
>>> l3 = arcpy.FromWKT('MULTILINESTRING((9703086.5310000032 4431846.6370000001,'
... '9703086.5308749974 4427846.6367499996,'
... '9704269.3477500007 4427852.6163749993))')
...
>>> l3.overlaps(l2)
False
>>> l3.crosses(l3)
False
>>> l3.touches(l3)
False
>>>
From one set of definitions, the examples don't overlap, cross, or even touch themselves, which makes it fairly difficult to identify the geometries that "self overlap." The ArcPy Geometry classes, unfortunately, do not have a self-overlap method or anything similar. For the Python implementations (Shapely, GeoDjango) of JTS/GEOS, the closest approximation to a self-overlap method for lines is is_simple:
>>> from shapely import wkt
>>>
>>> #OBJECTID 1
>>> _l1 = wkt.loads('MULTILINESTRING((9700614.7831249982 4432945.8557500001,'
... '9700614.7831249982 4427945.8557500001,'
... '9700614.7831249982 4428945.8557500001))')
...
>>> _l1.is_simple
False
>>>
>>> #OBJECTID 2
>>> _l2 = wkt.loads('MULTILINESTRING((9702086.5310000032 4431846.6370000001,'
... '9702086.5308749974 4428846.6367499996,'
... '9702086.5308749974 4428846.6367499996))')
...
>>> _l2.is_simple
True
>>>
>>> #OBJECTID 3
>>> l3 = wkt.loads('MULTILINESTRING((9703086.5310000032 4431846.6370000001,'
... '9703086.5308749974 4427846.6367499996,'
... '9704269.3477500007 4427852.6163749993))')
...
>>> _l3.is_simple
True
>>>
While it is clear that OBJECTID 1 is not simple because it "self overlaps," or folds back onto itself, it is less clear why OBJECTID 2 is simple. Since JTS/GEOS libraries are OGC compliant, consecutive equal vertices are allowed in a LineString. A basic simplify operation will remove not only redundant vertices but also some intermediate vertices if not necessary to the topology of the line.
>>> _lc = wkt.loads('LINESTRING(0 0, 1 0, 1 0, 2 0, 2 0, 3 0, 3 0, 3 0)')
>>> _lc.is_simple
True
>>> _lc.simplify(0).wkt
'LINESTRING (0 0, 3 0)'
>>>
Instead of continuing this already-too-long comment, I will wrap us this aside and post another comment with additional thoughts.
UPDATE: OBJECTID 2 in my code above is not the same as OBJECTID 2 provided by OP. I must have miscopied the WKT representation of OBJECTID 2 and created a line with duplicate end points. Instead of correcting OBJECTID 2, I will leave it as is to discuss the situation when a line has consecutive vertices that are equal.