There's a third axis, which is "coding time". A simple algorithm might work fine, but to deal with scale/complexity/corner cases you need a more complex one which runs twice as fast, but takes twice as long to write. If the run-time of that section of code is a tiny proportion of the total run-time then why invest in speeding up that part?

Most of the time you can get around that by hiding complexity - have the merge-sort sit, super-optimised, behind a standard API and you don't have to worry about optimising your code.