The kernel documentation says it best:
Sometimes it happens that a request enters the io scheduler that is contiguous
with a request that is already on the queue. Either it fits in the back of that
request, or it fits at the front. That is called either a back merge candidate
or a front merge candidate. Due to the way files are typically laid out,
back merges are much more common than front merges. For some work loads, you
may even know that it is a waste of time to spend any time attempting to
front merge requests. Setting front_merges to 0 disables this functionality.
Front merges may still occur due to the cached last_merge hint, but since
that comes at basically 0 cost we leave that on. We simply disable the
rbtree front sector lookup when the io scheduler merge function is called.
The reason front merges are uncommon is that writers typically do not write blocks to disk in reverse order.
Consider a process which does a simple sequential write of a new file containing two blocks. It first writes block 0, then writes block 1. When block 1 hits the queue, it is in the back of block 0, so the kernel does a back merge, then sends both blocks to the physical disk at the same time. This is the typical case.
To get a front merge, the process would first have to write block 1, then seek backward and write block 0. This isn't the typical case, though for some workloads it does happen (e.g. databases).
I wouldn't expect the change in performance to be that significant here, even with high I/O. You can test it both ways on your actual workload. If you aren't doing something disk intensive, then this isn't really important.