Especially for server applications running a long time, a leak can bring down a server. If you just leak 5 KB per second on a server script, this may be over 2 GB in a week ending up in swap storage. If it's slow enough, it will fill your server's disk with swap files, but if it leaks fast, it will also hit performance a lot!
We do static analyses on our source code to find leaks. We do use C++ classes to automatically free memory when they are released, e.g. on function end. And we use NSAutoreleasePools on Mac to collect objects and release later. We try to get memory management right and automatically get there. But there may always be things not found by us.
A memory leak you report should be reproduced in a small script/method, which can be run several times. First call my do initialization steps and trigger some framework initialization, but any subsequent call should result in a higher memory usage each time. This method may have a loop to the relevant steps a 1000 times to make it a significant leak. On the end, you should have leaked a few Megabytes, so we can look for big objects not freed or thousands of small objects of the same type. Make sure you do all the release/free calls as provided by the plugin.
Due to memory management, memory is allocated in chunks. Memory is freed with delay, so you may need a short pause for memory pools to be cleared. So two or three runs may allocate the chunks
A lot of frameworks we use do leak themselves. e.g. Cocoa framework on Mac has a lot of small leaks. So in general we are not really looking for leaks which just leak a few kilobytes every few minutes. Watching a Cocoa app in Instruments we see a lot of small leaks. We prefer to fix the leaks in our code!