Because the client is currently only given data about nearby objects. The only real solution is to break up the .png into smaller chunks which will never be out of range. The safest bet in this case would be for each chunk to have one-half the dimensions of world.view (so you can fit four chunks on screen at a time).

You can also use the old map_format which will chop it up into 32x32 chunks and create a new turf for each chunk, but I suggest not doing so.

<edit>Actually, I mis-remembered how large the chunks should be. You can't see things beyond 4 tiles off the edge of your view, so they should be 4x4 tiles at most (ie: if your tile size is 32x32, then 128x128 chunks). However, you can use pixel_x and pixel_y so that the location of the actual object is the center of the icon, so you can use 7x7 chunks with pixel_x and pixel_y being -3 tiles (ie: at 32x32 tiles, chunk size is 224x224 and pixel_x/y are -96).

Thankfully, a great and simple solution here is to simply split the image between each turf (so it's split to parts sized world.tile_size).
This used to be automatically done by the map editor when laying an atom whose icon was assigned to a large graphic, but with the new, default world.map_format setting this functionality is unfortunately lost, even though it's still useful in it.