The most important thing to remember is that routes are not static. By design, routes on the public internet are changing all the time. Sometimes routes change due to load balancing; sometimes they change because a node goes down; sometimes they change because routers decide literally at random to change the routing rules (just to shake things up).
From the perspective of an end-user who does not have System Administrator-level access to every single intermediate router and internet hub between the origin and destination of a packet, you have to treat it kind of like the Heisenberg Uncertainty Principle.
Things to consider:
Based on the declared IP "destination" in your packet, intermediate routers may decide to route you differently. Therefore, if a traceroute is an attempt to sequentially map the routers between source and destination, a traceroute can be thrown way off course by having routes take different paths depending on which node you're trying to reach.
Not all routers will listen for ICMP or UDP pings. They may choose to silently ignore this traffic and just drop it at the NIC (often to help combat DDoS). This can frustrate your attempt to map a route.
Even if you successfully map a route, and all intermediate nodes reply to your pings and don't attempt to play with your mapping attempt, the route may change for the next packets you send using some "real" protocol (or even if you attempt a traceroute a second time).
QoS may cause normally-behaving networks to route traffic differently. For instance, VoIP or streaming video may take one path, while regular web browsing may take another.
The type of traffic may cause the routing to differ. For instance, even without considering QoS, you may get a different path for FTP than you get for SSH. The intermediate nodes can exercise any discretion whatsoever (anything from a totally random selection of routes, to a malicious attempt to slow down your traffic, to an honest attempt to make your connection faster by routing to the node with the least load) when determining where to route your traffic from each hop.
In theory, intermediate routers could also, if they so desired, turn your traceroute attempt into an infinite cycle: node A points to node B, node B points to node C, and node C points back to node A. There is nothing stopping the routers from doing this (I'm not sure why they would choose to, but it's a possibility) for packets detected as "traceroutes" (ICMP or UDP pings). It can do this to attempt to foil your efforts, or for any other reason.
The Multipath Discovery Algorithm is useful, but it cannot overcome these theoretical limitations.
Basically, in order to determine a path, you have to send one or more packets. Those packets can be routed in any way the intermediate nodes see fit. But as soon as you send another packet, there is absolutely nothing stopping the routers from changing the path. This is sort of a networking analogy of the Heisenberg Uncertainty Principle.
Paths are ephemeral and transient. You should not rely on information received from a traceroute for anything important, except to diagnose a connectivity issue on a network where you already have deep knowledge of the topology (on a complicated corporate LAN, for instance), and can control the behavior of the participating nodes. If any of the participating nodes aren't "yours" (if you can't log into them with system administrator privileges), the results of the traceroute are effectively arbitrary.
On the other hand, if all of the participating nodes are yours, you can, as administrator, control the exact behavior of each node. For instance, you can enable ICMP, and set up static routes (routes that don't change). You can then be confident that your traceroute is accurate. But if you put a load balancer in the middle, then you will have to be aware of the load balancer's behavior and the way that it can switch routes pretty much as needed (although it generally isn't random and generally doesn't try to deceive you on purpose).
