But the program performs functionally the same.
That's the rule followed when doing compiler optimisations.
memset has nothing to do with Heartbleed by the way, nor does any compiler optimisation.
The program will generate the same output yes, but the security implications are not the same.
This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable. Furthermore, the most common reason for using custom mallocs in security-critical applications is to do exactly that - to zero all memory immediately upon freeing.
Zeroing memory like this is a common practice in such cases.
You also don't guarantee the original data is overwritten. If your application is paged out of RAM before the call to memset, when it gets loaded back in to RAM it can be pointing to a different physical memory location. You're now overwriting.... something completely different.
This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.
Now, what is true is that additional copies of the data could be made, but you'd need to have escalated to root to access anything in a pagefile (at which point your system is completely compromised anyway), and I'm not even sure if direct access to L1 cache is possible.