As for performance, there are various ways to handle this. If your system is only interested in say 10 of the 5000 entities in the scene, you might instead setup a list this system manages based on some event callback system so that the update loop is much faster and iterates over the smaller subset list managed directly by that system. For use cases where you only ever have 1 instance of a component in the scene, you might find storing those types of components differently can drastically improve performance; see presentation at GDC from Blizzard's Overwatch team about Singleton Components

I'm confused why an entity needs a reference to the map or map data at all. If your entity is physics controlled, the tile that doesn't permit movement would report a collision, you'd check the contacts and not allow the movement. You might even play a sound when this occurs to give some audio queue. If the entity is not physics controlled, then your movement system does a SpatialQuery to your SpatialSystem to determine if the intended movement is permissible. It's generally acceptable for SystemA to consult SystemB for use cases like this, so storing spatial data separately is good.

In my experience, if your entity system consists of only the entities visible in the area of view around the player, chances are the majority of those that can move are often doing some form of movement frame-to-frame. There will be some which likely won't because their wander behavior may have entered a pause state for a few seconds, but generally speaking those are considerably fewer than those that are actively moving.

How you choose to store entity data obviously can have an influence on how you may mutate data. However, I don't understand your reference to map. Our component storage system allows us to iterate components in a cache friendly way in contiguous memory while also being able to fetch and iterate sibling components in a similar way. So for movement it boils down to a tight loop which calculates a vector3 of movement and we then apply said movement to the rigid body or non-physics controlled entity.

Why not expose the moveTo method as a part of the underlying system in your use case, e.g. MovementSystem? This way not only then can you use it in the scripts you write but you can then also use it as a part of the C++ code too where you need it. So yes you'll have to expose new methods as new systems are added, but that's to be expected as its entirely new behavior these systems introduce anyway.

@Nik-Lz In a very generic way, yes. My goal was to abstract away the component system registration & array management behind the entity manager so that the code which builds entities remained clean and did not need to know anything about the systems themselves. I have since reworked the loader where I dispatch the model data to a series of callbacks that systems register at startup. This allows each system to build the components without the loader needing to know about them either. It then boils down to a "link/sync" step and then runtime queries during the game loop.

@Nik-Liz The whole premise here is to reuse entity ids that have since been destroyed to avoid running into potential issues in long-running simulations. From your perspective, index = your pure integer value and then version is just a numeric value that you increase every time that entity dies. When an entity dies, you push the EntityID onto a stack and reuse those EntityIDs first before allocating any new ones.