Without having looked at the code I assume that's because administrative units and historical places are linked to the place, not the object. So you would have to get the place (E53) linked to the object (E18) with "has location" (P53) and than get them via "falls within" (P89).
e.g. at place_update() in views/place.py the location "brings" its own types/nodes (including admin. units and historical places):
object_ = Entity.get_by_id(id_, nodes=True, aliases=True, view_name='place')
location = object_.get_linked_entity_safe('P53', nodes=True)
This is just the technical answer but raises the questions how we want to deal with it in the API. In the user interface object and place are presented as one and I guess it would make sense to do the same in the API since it's a 1:1 relation. So one way to stay CIDOC CRM conform would be to present a "sub entity" E53 with all the links when requesting the object (E18). Be aware that there can be multiple links, e.g. a region spans multiple historical places.
Feel free to ask, meet or discuss at next API meeting if you need more information.
Updated by 
Updated by