The downside is that your program will use more total memory than it actually needs, since every allocation will increase the total memory used, rather than reusing memory that was previously freed. Depending on how long the program runs, this could add up, and slow things down.
As an example, imagine if you did this in a text editor where you edit many files. When you close a window, all the memory associated with that file will still be allocated, even though it's not being used for anything. If you're like me, you keep the editor open all the time, editing various files and closing the ones you no longer need. If it didn't free all the allocations when closing a file, the memory use could grow enormously, since I rarely exit.
Freeing memory as soon as it's no longer needed allows the heap manager to reuse that memory rather than increasing the total memory footprint of the process. While modern systems have lots of memory, both physical and virtual, it's not infinite, and if several large applications worked the way you describe you could run into problems.
There are also applictions that are intended never to exit, e.g. webservers and system daemons.
Do you have a DVR that reboots every day? One possible reason is because the programmers took shortcuts and don't free memory when it's not needed, so the memory just keeps growing, and they reboot to clear the memory before it runs out.

Just about every modern operating system will recover all the allocated memory space after a program exits. The only exception I can think of might be something like Palm OS where the program's static storage and runtime memory are pretty much the same thing, so not freeing might cause the program to take up more storage. (I'm only speculating here.)
So generally, there's no harm in it, except the runtime cost of having more storage than you need. Certainly in the example you give, you want to keep the memory for a variable that might be used until it's cleared.
However, it's considered good style to free memory as soon as you don't need it any more, and to free anything you still have around on program exit. It's more of an exercise in knowing what memory you're using, and thinking about whether you still need it. If you don't keep track, you might have memory leaks.
On the other hand, the similar admonition to close your files on exit has a much more concrete result - if you don't, the data you wrote to them might not get flushed, or if they're a temp file, they might not get deleted when you're done. Also, database handles should have their transactions committed and then closed when you're done with them. Similarly, if you're using an object oriented language like C++ or Objective C, not freeing an object when you're done with it will mean the destructor will never get called, and any resources the class is responsible might not get cleaned up.