Firstly, effects do not leak as long as you remove them after they are not needed. Basically many inexperienced triggers fall into a trap of believeing "cause I can not see them, they have been destroyed". Even if the animation fades to nothing they still are rendered at that location and so eat up system resources. Destruction of the effect will remove 100% of the leaks (the model used will still remain loaded and eat up memory but that is not of any concern as it has near no upkeep). With effects attached to units, the same applies however if the unit is removed (after death) the effects are probably not rendered (no visual lag) but the objects probably leak, so make sure that you destroy every attached effect. Even if the unit is removed which the effect was attached to, removal probably will still succeede (I see no reason for it to not).
Playing the same sound object over and over again does not leak, it has no possible reason to as nothing is being made or destroyed (only sound generated which the sound engine deals with).
The leak they refer to is if you make new sound objects each time (load them from a path instead of reusing an already made sound object with the sound). As you can not remove sound objects, they will leak.
Lock camera to target does not leak. It has no reason to as it does nothing but force the player to equivently have the units avatar held (which locks camera ingame to a unit).
Most GUI actions however leak handle reference IDs, meaning the handle ID used to represent an object can not be recycled. This is due to them using local handles and not nulling their contense before destruction (a blizzard recycle bug). This however is automatically fixed when you optimize your map with vexorians optimizer as it changes all the leak BJ functions to leak free custom ones (which are slower but make up for the speed by not slowing the game with leaks).
Equally well, the handle reference ID of any handles (or agents) stored in globals can not be recycled until you null the global. In the sace of variables which are recycled often this is not a problem, however for once off variable storage (for a quest or map initialization), it can result in leaked handle IDs. Thus if you are not going to update a global handle in a long time, you should null it before hand.
Objects (handles) which never are removed are exempt from this as their handle index will never be recycled. Players for example do not need to be nulled, nor do multiboards as long as the same one is reused throughout the game until the game end.
Floating text can not really leak, as it has a fixed 100 size handle index space. If you run out of indexing space it recycles the last created text object. Impropper use however can result in bugs like floating text not being visible when it should.
