Hi Zach, thanks for the nice feedback!
Unfortunately I don’t really know unified resources about game dev in general, except maybe the videos of the talks from GDC (https://www.youtube.com/channel/UC0JB7TSe49lg56u6qH8y_MQ and/or http://www.gdcvault.com/). Some talks are awesome and very instructive on specific aspects, some talks are less interesting, but there are definitely good things to find there.
In addition, I can cite a few books about game AI, if you are interested. To be fair, I’m sure there are good books about general game dev, but I don’t have personal experience with one.
Other than that, the way I learned was by intense trial & error and googling. Working with a game engine/framework (such as Phaser) is also useful in that respect, because existing engines tend to follow the best practices of the field and allow you to grasp better how all the moving parts of a game fit together.
If there are specific topics on which you don’t find satisfying information, don’t hesitate to let me know, if I feel qualified I can try and write a post about it. 😉

In that sense it is similar. But even with no obstacles the player needs to know the status update of everything around it because a) it is moving constantly, or accelerating. b) the environment around it can change rapidly, for example, a large amount of foods are spawned and quickly eaten by someone else.

I don’t divide the map into grids because I think changes are too often and I don’t want to end up checking too many adjacent grids. I am using spatial hashing + radius to cull the elements now.

For this, it seems to me that interest management (IM) based on rectangular areas would be perfect, wouldn’t it? Typically these games don’t have visual obstacles, so vision-based interest management would boil down to determining what is on the screen, which is then similar to area-based IM.

I am writing a agar.io/slither.io type of game. Unlike Phaser Quest. every entity in my game can change its status. A player can spawn at a new place and can be killed anywhere on the map. New food will respawn everywhere and some flying objects (or we call NPCs) will be wandering across the entire map randomly. The only thing that doesn’t move is the food entity but when a food is eaten it disappears on the map.

Yes the approach you describe is often used but can be very tricky, and also quite expensive. What kind of game are you making? It might be worth comparing the benefits of your approach and the benefits of mine. Mine will cull less game objects, but it’s a breeze to implement, which is nice (and for a top-down game such as Pahser Quest, vision-based culling doesn’t make much sense anyway). If the result is good enough, a simpler solution may sometimes be preferred.
Also, this one can go hand in hand with a chunk map management system, where on the client side you only load “chunks” of the whole game world that are relevant to the player (I’ll write something on that soon).
I don’t have direct experience with vision-based interest management, so unfortunately I wouldn’t be able to write a good article about it!

Diablo 2 was plagued by a program called MapHack, which showed the location of other players on the map (as well as monsters, loot, etc).

Yes it can, but only to a certain extent. Simply obfuscating the data exchanges is never sufficient in terms of hacking prevention, you need the server to validate absolutely everything that the clients send to be sure. Once this is the case, it doesn’t really matter anymore if the players can see all the data that is exchanged.
This is something I haven’t covered yet, but I might in the future!