You could go a more functional data route and parse the strings into Numpy arrays or even NamedTuples. There aren't a ton of methods you'd need beyond what is in Entity, so it seems doable. Keeping track of what was what in each array is up to you.
A numpy array isn't necessarily going to improve speed if your code is composed mostly of full loops over the array and conditionals. Reducing the number of iterations, branching and local data that must be GCed are all up for grabs here, but probably have a tiny impact rather than a big win.
An array of arrays that form a grid (which I think was what Halite 1 used? I didn't compete so I am not sure) is more practical for matrix math and doing searches because it only has a few discrete positions and finding nearby locations is easy.
Halite-2 uses a floating point location system, so the map doesn't fit into an array-of-arrays so easily. However, I have thought about "
flooring"/downsampling everything to integer coordinates in my bot's representation. It wouldn't speed up distance calc (back to floats), but I was thinking normalizing all maps down to the smallest 3:2 map size (240x160) with integer coordinates might be an interesting way to feed the entire map to machine learning as features. (I have not tried this, YMMV. My interest is more in passing in ships with world data one at a time as features.)
Honestly, moving to more efficient IO, or moving to a compiled language, is the biggest easy win here.