Then your design is broken. The spatial is not a game object.
Basically, all things that are “game object” should be in the ES. Spatials are not game objects.
If you want to think of it this way, imagine that you are showing a 2D and 3D view of your game. To some players your game will look like a 2D isometric style game with sprites and tiles. To some other player, the game will be fully 3D. To some other player, it will be a top-down 2D view with just little icons.
What state would there be in common to all of these views? That’s the game state. That’s what the ES manages. It doesn’t matter if you are saving them or not.
The rest seems to fall out naturally from this, to me.
You use entity.get() in your normal systems because those normal systems are just grabbing the entities they are interested in. If that system is asking for components other than its interest for some rarer use-case, then obviously it goes back to the ES for that (EntityData.getComponent()) because that’s an “out of band” style request.
In general, that’s what makes the code more readable. Your eye sees myEntity.get(…) and your brain automatically knows this is a system watched/managed component. Your eye sees entityData.getComponent(id, …) and knows this is an unmanaged call that you do rarely. The latter case should also be gnawing at you that the closer you are to “Spatial country” the more likely it is that something is wrong.
It may also be helpful to think in terms of client-server usage even if you aren’t networked. myEntity.get(SomeClass) is going to be a local call in immediately available data. EntityData.getComponent(id, SomeClass) is very likely going to be a full round trip TCP request to the server.
If you are already on the server then no worries. If you are in the visualization layer then something may be wrong in the design. It happens but it’s very rare.
Either way, spatials should not be in components. Spatials “do stuff”. Components are 100000000% data only.