There are two things happening during this coordinate transformation: reverse projection (from x,y in meters to latlong) and datum transformation (from latlong in one datum to latlong in another datum). Now when the datum transformation properties are not fully known this whole datum transformation is skipped. This happens when no datum or to_wgs84 parameter is present.
When no transformation is selected in ArcGIS it skips the datum transformation, and interprets the latlong coordinates as being WGS84. The same happens in Google Earth, since the datum in the .prj file of a shapefile is usually not fully defined (not in the ESRI version at least, QGIS stores an additional fully defined .qpj file, according to OGC specifications).
The reason that in the end these untransformed coordinates are still different from interpreting them as WGS84 UTM 37N is that also the projection is dependent on the used ellipsoid. When the size of the ellipsoid is slightly different the conversion factor from degree to meter is also slightly different, giving a slightly scaled result.
Now to get the Google Earth/ArcGIS <None> behaviour in QGIS the proj4 string to be used should have an incomplete datum definition. By default all projections in QGIS are from EPSG and are fully defined, so a custom CRS should be added with incomplete parameters, like "+proj=utm +zone=37 +ellps=clrk80 +units=m +no_defs". Note that this always skips the datum tranformation, so it depends on the project CRS if it is displayed as wanted, in this case the display CRS should use the WGS84 datum.
To transform the shapefile to correct Adindan coordinates first convert it to WGS84 using an incomplete datum, and then back to Adindan using a fully defined datum. For example with ogr2ogr:
ogr2ogr -s_srs "+proj=utm +zone=37 +ellps=clrk80 +units=m +no_defs" -t_srs EPSG:32637 test_wgs84.shp test_adindan.shp
ogr2ogr -s_srs EPSG:32637 -t_srs EPSG:20137 test_adindan_correct.shp test_wgs84.shp
(Google Earth can also do the correct tranformation if the datum transformation parameters are fully known. If "TOWGS84[-166,-15,204,0,0,0,0]" is added to the datum definition in the .prj file it will do the datum transformation.)
Best Answer
When you save out a KML file from Earth, it should save the current "visibility" settings for each feature. There's no way to save only the currently visible (checked on) items. When opening the KML in ArcGIS, I believe it ignores the visibility settings of the features, so you'll lose that info.
Two ways I can think of to do what you want... 1.) Make a copy (copy/paste) of the KML in Earth, and then quickly go through and delete the features you don't want to export before saving out as KML. Or 2.) Export the full KML with visibility settings and use some other scripting or regex tool to go through and remove all Placemarks/Features that have visibility=0.