I don't really understand why. How would you distinguish between which (kinds of) core objects and which not? Will you not end up with a displayString on Object again?
You will not know all the 'why's in advance. The concrete answer is in the next developer's creativity.
What you can do in advance is to ask 'why not?'
Well, then we can argue why not put 'foo' on Object. I think we should try to get to a good API with concrete meaning. And preferably on Object, there should be as few methods as possible that can be interpreted in as many ways as you want.
And a reason that comes to mind to answer that is:
because 1) what are the odds to NOT needing to perceive an object?
And how would I perceive a complex object through a string? Would I then display multiple lines with all the data contained in the object?
2) what's the most obvious way to make objects perceivable one if not displayed as a string in some kind of screen/device/hologram/network-proocol/whatever?
I think this is the core of the issue. We can't have a single 'displayString' interface that cater for all of these requirements / contexts. That's where the visitor pattern comes in - where the "whatevers" can decide for themselves how best to represent the object depending on the context. This is especially true when the object / object graph becomes more complex. Perhaps I'm misunderstanding the word 'perceive' here, but in my world it can be widely interpreted, depending on the perspective of the viewer. And 'screen/device/hologram/network-protocol/whatevers are all quite different perspectives. This is why I think that displayString is even for my 'DomainObject' above a bit suspect. What if I want to display it differently (in the same application), but in different views?