1) Why aren't most leaks cleaned out automatically? For example, I trigger a point for a special effect without assigning it to a variable. There is no way I can retrieve the information of that point after the trigger finishes, so why is the game storing it in memory? Why doesn't it automatically erase every triggered group and location and everything at the end of each trigger? It's so obvious I almost can't believe the engine is written that way. But since it's not, wouldn't this be a fairly easy mod to do for someone skilled?
That is a very big question most of us have asked for ages. The only practical reason we came up with was that WC3 is horribly programmed as is evidence by many problems from OOS errors due to terrain deformations to crashes when units go out of bounds. This likely has routes with the origins of WC3 as a MMORPG and inexperience of Blizzard's dev team to RTS games of such flexibility.
What is even more astounding is that WC3 JASS uses an indirection table type known as handles in any case. This makes garbage collection considerably easier to implement and something one would expect in such a system. Speed is not even an excuse as the automatic garbage collection would likely be as fast or faster than manual object deallocation (what JASS uses) due to the JASS interpreter overhead. In C++/C garbage collection is often avoided as it introduces problems and overhead, especially with concurrency and real-time systems, that can be avoided by manual destruction. In the end manual destruction should be more efficient as the program then is implicitly told when an object is finalized (part of active job) as opposed to having to waste resources looking for objects that require finalization (separate dedicated job). On the other hand garbage collection can eliminate problems related to memory fragmentation if implemented using an indirection table with little extra overhead (the memory moves and indirection table would still be needed to achieve the same effect with manual deallocation).
Do not fear though as Blizzard has improved massively over the last 10 years. SC2 (the spiritual successor to WC3) has a very effective garbage collection system that will remove points, unit groups, player groups and strings automatically based on reference counters. Only by doing very stupid scripts can SC2 scripts leak.
2) If I have a leak (let say, a position entry) every 5 seconds throughout the game, does it matter? I mean, RAM is not really a problem any longer these days. Bandwith is irrelevant I think, because the information is already sent from server to receiver even if you destroy the leak afterwards.
Memory is not the critical factor, it is memory locality (for caches) and finite engine resources that cause the problem. Enough objects will cause the engine to crash due to some internal limit being exceeded.
Memory bandwidth has only to do with locality. If you mean network bandwidth then you have the wrong idea how WC3 works.
WC3 uses fully synchronous clients with a relay server. The server itself does not run the game session (light weight) where as the clients run the sessions in parallel (heavy weight). This means that hour long sessions of WC3 may only generate a few MB of traffic, probably a lot less than using facebook or even Hiveworkshop for that time.
This is the opposite approach of heavy weight server and light weight clients (as used by Diablo III and WoW) streams game state to the clients that is computed by the server. This approach is required when the state of the game is too complex to mirror with all clients (like a MMORPG) and where latency is critical (FPS games). The latency reduction comes from synchronous servers having at best a Round Trip Time delay (command to server, sever synchronizes command for a time and broadcasts command to all clients) where as light weight steamed state clients can achieve much less (command to server, sever executes command and the results can be streamed at a later time in the future, aka no return delay to execute the command).
