Well, algorithmically the code is rather absurd. You copy arrays in the recursion. The first thing to note is that a mergesort is fundamentally a list sorting operation not requiring any copying. Copying to an array at all makes only sense when you hope to exploit the better memory locality of array access. That, in turn, only makes sense when you do not use indirection when sorting but rather swap the underlying data directly. Which only makes sense for small data types.
So there are a lot of ifs and buts that mean it is easier to just work on lists directly. With regard to the List data type it is worth noting that you can get a considerable faster sort by violating the list invariances of doubly linked lists, sorting only the forward pointing list in O(n lg n) operations and then do a single pass through the result in order to reconstitute the backward list.
However, that means that your sorting is better done as part of the List implementation than as something using List as a blackbox.
If you take a list of typical recursive mergesort implementations, it is worth noting that they tend to skip half of the given list in order to arrive at the second sublist. Since skipping half of the given list is done anyway when sorting the first sublist, by letting the sort return the head of the second sublist one saves this only-skipping pass as well.
I seem to remember that the Linux kernel source has a pretty good list mergesort implementation (of course in C rather than C++) that basically only suffers from not hardcoding small lists which would save some O(n) amount from the overall O(n lg n) complexity. For comparatively small lists, this can make a noticeable difference.
The Linux kernel version also sorts sublists generally of size 2^k which has the advantage that one does not need to know the list length in advance (which is needed for splitting some n into almost equally sized parts), at the cost of about O(n) extra comparisons in the worst case.
Note that I am not at all talking about your C++ style: this critique is exclusively about the running time and memory requirements of the compiled code. I consider it a mistake to not consider this a part of the quality assesment of code.