I'm would actually have to say, despite proposing edits to focus on your train of thought, that looking into a true component design may help your design concerns. At the end of the day a component system breaks objects up into their specific collections of functionality. For example, you would make a component that handles the position of an object within the world. It would contain the data needed to represent that and then the component interface for a movement typed component would expose an Update() to handle movement updates over time, an other methods to kick off the movement processed by the update call like MoveTo(), TeleportTo(), RotateTo() and RotateBy() as examples.

This would make the answer be 'The object moves itself' I suppose, but it should be noted that the component design breaks the objects apart into their discrete functionality areas, otherwise known as, components. This has some added benefits, the one I like the most is maintenance (objects expand horizontally instead of vertically) followed by extensibility (you can often create entirely new objects by defining them instead of adding additional new components).

Hope this helps.

EDIT: Rewritten due to feedback stating I had not drawn the line clear enough for this answer to the original question.

I would like to clarify the question a bit more if possible. Should the logic that acts upon an object be internal or external to that object. The last part of the post specifically mentions about the longevity of the design as the basis for asking the question, to avoid trouble later on.

My simple high level answer is to keep all logic that acts upon an object within that object.

You do not need the world to move an object, all you need is the object to be moved and the vector representing the location to move to it. The world may come into play when a destination is being chosen or when a reaction to the environment is required due to collision, but those are outside of the example given to work upon.

To address the underlying part of the question and achieve longevity of the design I would suggest a component oriented architecture. Component architectures break down an object into discrete sets of data and functionality (assuming you go with my answer above which states to keep the logic with the data). If your structure looks like CEntity->CHuman->CSoldier->CPlayerCharacter then you will invariably get into issues where you need to alter some logic and depending where it goes in that tree (How many other types of humans are there for instance?) it can have sweeping affects on multiple object types.

A component system would instead have a set of interfaces that define what the CEntity object is made up of like ICompRenderable, ICompMoveable, ICompHealth, ICompInventory and so on. Where you would have CCompMoveableHuman and possibly a CCompMoveableSoldier and CCompMoveablePlayer to keep their individual movement patterns separate. So say the Soldier is altered to run in formations. This change will only affect entities built using that component.

So, to sum up I suggest you contain the logic with the data the logic applies to. I also recommend breaking up objects into discrete components to cut down the 'Where do I put this?' questions and provide stability into the future with ease of maintenance and its extensible.

Hope this helps.