Parallelism is a major reason for variation in the speed of these tools. Another contributing factor is how long they wait for a reply before the hop is considered to not be responding. If reverse DNS is performed, you have to wait for that as well. The plain traceroute command gets much quicker, if you disable reverse DNS.
Another important difference, which I did not see mentioned, is how the two tools render the output. Traceroute produces the output in order top down. Mtr renders output in a different way, where mtr can go back and update output on previous lines.
This means mtr can display output as soon as it is available, because if later replies cause that output to not be accurate, mtr can go back and update it. Since traceroute cannot go back and update output, it has to wait until it has ultimately decided what it will display.
For example if hop number 2 is not responding (which is a symptom I have seen on multiple ISPs), traceroute will display hop number 1 and then wait for a while before it displays hop number 2 and 3. Even though the reply from hop number 3 has arrived it is not being displayed because traceroute is still waiting for the reply from hop number 2. Mtr does not have that restriction and can display the reply from hop number 3 and still go back to display the reply from hop number 2, if it arrives later.
Too much parallelism can cause the output to become inaccurate. In some scenarios there are limits to how many packets you can get replies for. Sending more packets in those cases will not speed up the process, it will however cause more lost packets, as you get the same number of replies with more packets being sent.
One example of this is when a hop on the route does not reply to ARP requests. Usually the first packet will trigger an ARP request, and if more packets arrive before the ARP request times out, only the last of those packets will be buffered and get a reply.
Another difference is in how many hops with no responses will be displayed before the tool stops displaying more hops. I have seen the traceroute command continue for as many hops as requested (30 by default), while the mtr command would stop as soon as it had passed five hops with no responses.