How’s this possible when the program always assign a free memory
location to a variable? How could it be something rather than zero?

Let’s take a look at an example practical implementation.

Let’s say it utilizes stack to keep local variables.

void
foo(void)
{
        int foo_var = 42;
}

void
bar(void)
{
        int bar_var;
        printf("%dn", bar_var);
}

int
main(void)
{
        bar();
        foo();
        bar();
}

Totally broken code above illustrates the point. After we call foo, certain location on the stack where foo_var was placed is set to 42. When we call bar, bar_var occupies that exact location. And indeed, executing the code results in printing 0 and 42, showing that bar_var value cannot be relied upon unless initialized.

Now it should be clear that local variable initialisation is required. But could main be an exception? Is there anything which could play with the stack and in result give us a non-zero value?

Yes. main is not the first function executed in your program. In fact there is tons of work required to set everything up. Any of this work could have used the stack and leave some non-zeros on it. Not only you can’t expect the same value on different operating systems, it may very well suddenly change on the very system you are using right now. Interested parties can google for “dynamic linker”.

Finally, the C language standard does not even have the term stack. Having a “place” for local variables is left to the compiler. It could even get random crap from whatever happened to be in a given register. It really can be totally anything. In fact, if an undefined behaviour is triggered, the compiler has the freedom to do whatever it feels like.

If you don’t initialize an variable that’s defined inside a function, the variable value remain undefined.

This bit is true.

That means the element takes on whatever value previously resided at that location in memory.

This bit is not.

Sometimes in practice this will occur, and you should realise that getting zero or not getting zero perfectly fits this theory, for any given run of your program.

In theory your compiler could actually assign a random initial value to that integer if it wanted, so trying to rationalise about this is entirely pointless. But let’s continue as if we assumed that “the element takes on whatever value previously resided at that location in memory”…

How could it be something rather than zero(I assume that default free memory value is zero)?

Well, this is what happens when you assume. 🙂

This code invokes Undefined Behavior (UB), since the variable is used uninitialized.

The compiler should emit a warning, when a warning flag is used, like -Wall for example:

warning: 'i' is used uninitialized in this function [-Wuninitialized]
  cout << i;
          ^

It just happens, that at this run, on your system, it had the value of 0. That means that the garbage value the variable was assigned to, happened to be 0, because the memory leftovers there suggested so.

However, notice that, kernel zeroes appear relatively often. That means that it is quite common that I can get zero as an output of my system, but it is not guaranteed and should not be taken into a promise.

Static variables and global variables are initialized to zero:

Global:
int a;  //a is initialized as 0

void myfunc(){
   static int x;     // x is also initialized as 0
   printf("%d", x);}

Where as non-static variables or auto variables i.e. the local variables are indeterminate (indeterminate usually means it can do anything. It can be zero, it can be the value that was in there, it can crash the program). Reading them prior to assigning a value results in undefined behavior.

void myfunc2(){
   int x;        // value of x is assigned by compiler it can even be 0
   printf("%d", x);}

It mostly depends on compiler but in general most cases the value is pre assumed as 0 by the compliers

int i;
cout << i;

Since C++26, this is erroneous behavior.
i is default-initialized, which means that no initialization is performed, and it has erroneous value.
This means that i could have e.g. value 0 (or some other value), but you’re not really supposed to use it.

When it is being accessed in cout << i, that is erroneous behavior.
The program could just print the value of i and move on as usual, but it could also crash as the result of printing i.
Also, the compiler should give you a warning.

Prior to C++26, this is undefined behavior, as explained by the other answers.
Note that the value 0 is particularly likely, even when the memory is considered indeterminate or erroneous by C++.
This happens because the operating systems regularly fill pages with zero, so if you can often get zeros by coincidence.

See also What is erroneous behavior? How is it different from undefined behavior?, and Where do the values of uninitialized variables come from, in practice on real CPUs?