I think the image assumes that the viewer is familiar with merge sort, which is something you will learn in basically every undegraduate CS program, then never use.

To answer your first question, it helps to have something to compare it against. I think the most obvious way of sorting a list would be "insertion sort", where you look through the unsorted list, find the smallest element, put that in the sorted list, then repeat for the second smallest element. If the list has N elements, this requires you to loop through it N times. Since every loop involves looking at N elements, this means you end up taking N * N time to sort the list.

With merge sort, the critical observation is that if you have 2 sublists that are sorted you know the smallest element is at the start of one of the two input lists, so you can skip the inner loop where you would search for the smallest element. The means that each layer in merge sort takes only about N operations. However, each layer halves the number of lists, so you only need about log_2(N) layers, so the entire sort can be done in around N * log(N) time.

Since NlogN is smaller then N^2, this makes merge sort theoretically better.

Feels like the one who created this didn't want to do step 3 to 5 for all levels.