In this particular database I always advise to use the full path, or Key, to reference entities, because the id could be repeated across entity groups; very simple example:
Key('user', 1, 'post', 1)
Key('user', 2, 'post', 1)
This is perfectly valid, and if you only store the post id then there's no way to know to which user the entity belongs to.
And as @tx802 mentions development is easier overall, as entities can be fetched directly; even as you move them back and forth between client and server, there's no need to be recreating them.
The only downside may be storage/bandwidth increases, but that's only a problem when you are handling "big data", and even then it's unlikely to be an important issue.
All entities have a key. The difference you're asking between is whether you should use
Key('Parent', 'dad', 'Child', 'ali') # Name
or
Key('Parent', 'dad', 'Child', 1) # ID
I would use Name where I can. That is, if your entity has a unique name. In this example 'dad' can have only one child called 'ali'. The key is essentially your primairy key (if you want to compare it to something in SQL). Note that Key('Parent', 'dad2', 'Child', 'ali') is a totally different Key and is legit to do. Also note that 'dad' or 'dad2' don't need to exist in the database if you want to store 'Child' entities.
I would use ID when I have entities that I either cannot reference by name or whose name could possibly change. The key of an entity can never change.
I would not bother with space usage in keys. IMO the cost benefit wouldn't weigh up to the benefit of readability.
I use IDs as part of my URLs when showing information to users. A URL with a key:
http://example.com/user/b3Bhdm90ZXIVCxIIRWxlY3Rpb24YgICAgIDQuwoM
is much uglier than a URL with an ID:
http://example.com/user/5891733057437696
I don't use ancestors so I don't have issues with multiple IDs, though I suppose two IDs in a link is still shorter than a key.
The answer to this probably depends on a balance between your expectation of the need to migrate data vs visibility to users/people:
If you may need to add a root or intermediate ancestor to the key in the future, and need existing references to remain functioning you should use a key (or a websafe key for use in the client). This ensures existing data continues to work.
If you cannot guarantee a unique id (for example using incrementing or generated ids), you should probably use a key. This is because ids (and names) are only required to be unique within their parent. If you use for example a UUID, this would not be a concern.
If your entities are short lived and you want neat urls, you may just use an id/name. If you are emailing links, or relying on them to be long lived for SEO, you probably need to encode a key somehow (again, in case you need to migrate data in the live system)
In my experience data migration is a real concern because of some of the more unique limitations of the datastore (write limits per entity group and entity group limits per transaction). This means you sometimes need to remodel existing data. Whether or not you need to bulk migrate or not really comes down to how you stored relationships in the first place. The core problem is you cannot migrate references held externally (urls in emails, SEO indexes, api endpoints etc), so you will break functionality for some subset of users when you make assumptions about the ancestor 'path' in an entity's key.
