Programming

Hopefully.
Sure, it can be. Is this statement general or based to issues you have with your application ?
It will eventually.
A memory leak will first slow down the system when no more RAM is available and the OS start paginating (swapping pages) intensively. After some time, the system might starve virtual memory too. What will happen will depend on what OS and kernel you use. Linux is known for its controversial OOM killer, a kernel task that blindly kill processes in order to free some memory.

memory leak problem should not be handled carelessly and should not be left to OS to handle that. It should be handled with care.

On your desktop or test host only ( not in prod ), write a program that only does malloc() without free() for every 30 seconds and see the system performance over period of time. Difference will be quite obvious.

Also, think of a ever running program like daemons and a memory leak problem in it, over a period of time, this memory leak problem will manifest itself and disturb the system.

No. Completely no. Heap memory is released when the process ends, whether or not the program called free(). The memory is released. After a process ends, the old process heap memory is no longer allocated to any process. Read man page for brk().

For long running programs and BEST PRACTICE in C coding, always call free().

I put this here as a correction. Not a comment.

Then I undertand that memory leak is meaningful as long as the process that caused it is alive. Once the process that caused it dies then all the leaked memory will made available to the OS memory manager. Am I right?

Correct. All memory - even leaked memory - that belongs to a process is reclaimed on process termination.

Considering the lifetime of a process, assuming that its short lived and its not ok to accept memory leaks in the code.

1. Same thing might happen to a daemon - which will bring down system
2. Trigger OOM errror
3. A bug in short lived process (assuming its short lived) which eventually might be using up all the resources.
4. Even for a short lived process, if the memory consumption is exponential, then we are done in much lesser time

So, the rule is - no memory leaks in the code and no memory leaks whatever be the life span of the process memory image

Except at runtime because the process can consume all 4Gb (32-bit process) such that it ultimately freezes and cannot continue. On machines with little RAM this is a serious problem as it can prevent other processes from starting or allocating memory. When the leaking process terminates all memory allocated from text data and stack segments is released.