All programmers cause memory management issues, even the folks who write garbage collectors. Those folks have typically forgotten more about memory management than you or I will ever know. If you do not have a compelling reason to believe that you will be better than them quite literally all of the time, then you might want to learn to love the GC.
(See also: trying to out-optimize both gcc and the processor pipelining which you don't really understand anyhow, reimplementing core features of your web stack to "do them right this time", etc etc.)
With garbage collection it's possible to have perfectly correct code which nonetheless breaks horribly as a result of the garbage collector being "smart" in very stupid ways.
Some of them are:
1) are auto-freeing templatized heap object class (the compiler will automatically call destructor when objects goes out of scope, call free in the destructor).
2) Overload free/delete to fill up freed memory with 0xdeadbeef etc so that code that reads from there is likely to crash due to invalid data.
3) Use one of the non-libc memory managers which will track memory allocs and frees and tell at exit if all memory was freed. Some will even have tricks to tell you which allocation was not freed.
4) If all else fails, use Valgrind for the really tough ones.
Coupled with a good regression/unit test suite, memory leak tracking will be an insignificant part of your development effort.
Without a doubt, the #1 biggest waste of time in coding the application is the manual memory management required in C++. Symbian C++ is particularly horrible, but the memory management still sucks even when I get to write "standard" C++. And, it sucks right from the beginning (which kind of smart pointer do I need here?) through the middle (does this API call take over ownership of this pointer or not?) all the way through the end (am I sure I got it all correct before I pay for this $200 signature?). I can take some shortcuts in the C++ versions because they have more memory to work with than the Java versions, but still the memory management is a much bigger hassle in the C++ versions than in the Java versions.
Windows Mobile is probably the worst because it has a pretty low market share, it is expensive to get started, and it is pretty tedious to code for.
Symbian is the most tedious to code for but it has a huge market share.
The iPhone SDK is the only way to make iPhone apps, and the iPhone is obviously very important so you can't ignore it. It was the most expensive to get started for because it more-or-less requires the purchase of a Mac.
Android is easy to code for right now but I've heard that the Cupcake update is causing a lot of people pain. When more devices from more manufacturers are released on more carriers, we may find that Android is not much better than Java ME in terms of ease-of-coding.
For smallish programs like what you describe, I agree that manual memory management can be decent overhead.
Many "big" projects try to reduce the memory management hassles by embedding an interpreted language such as Tcl or Lua for implementing non-performance intensive tasks.
I'm not advocating writing everything in C++, but with the right tools and in the right circumstances, the benefits of C++ can outweigh the annoyance of manual memory management.
Another reason I'm skeptical of garbage collection is because I read that unless you do things in a specific way you can have references hanging around in Java resulting in memory bloat.
Bah. Your original comment was that GC became too slow, not that it didn't work correctly. Using malloc/free, you're dependent upon the system allocator, and so you have no time or space overhead guarantees from the allocator. Chaining free coalesce, OS paging, etc. can easily make you miss a soft-realtime deadline, make your UI pause, etc.
Obviously manual memory management is very dangerous and straight up not for the average programmer.
But if you look thorough GC code by great hackers. You'll notice a style that looks almost like free/malloc in that they take deliberate care to make life easy for the GC.
And on the other hand, programmers who are completely oblivious to how memory works, often write code which can confuse even the best GC so much that you essentially end up with a big memory leak. Strictly speaking the memory isn't leaking, the GC just can't quite dare clean it up.
The lesson is, even the best VM and GC won't make bad programmers into good ones.
Dunno about you, but if I accidentally use 800 kB of stack, I want the computer to emit fire every time the function is called.