Where the remaining memory of vm.overcommit_ratio goes?

What the system will do with the remaining 20%?

The kernel will use the remaining physical memory for its own purposes (internal structures, tables, buffers, caches, whatever). The memory overcommitment setting handle userland application virtual memory reservations, the kernel doesn't use virtual memory but physical one.

Why is this parameter required in first place?

The overcommit_ratio parameter is an implementation choice designed to prevent applications to reserve more virtual memory than what will reasonably be available for them in the future, i.e. when they actually access the memory (or at least try to).

Setting overcommit_ratio to 50% has been considered a reasonable default value by the Linux kernel developers. It assumes the kernel won't ever need to use more than 50% of the physical RAM. Your mileage may vary, the reason why it is a tunable.

Why I should not always set it to 100%?

Setting it to 100% (or any "too high" value) doesn't reliably disable overcommitment because you cannot assume the kernel will use 0% (or too little) of RAM.

It won't prevent applications to crash as the kernel might preempt anyway all the physical memory it demands.

Setting the ratio to 100% will not reserve any space for file-backed pages, or in-kernel allocations such as kernel code, network buffers, etc.

In-kernel structures will be allocated regardless, causing overcommit. They're generally limited individually (e.g. there's a setting for network buffers). I don't think there's an overall limit of 50%, although an overall limit is something that's been worked on for the purpose of hosting containers.

File-backed pages are where you usually run userspace code from, so you need space for that too.