More to the point the article goes on at length about why traceroute is a bad tool, but it doesn't offer any alternatives. Sure traceroute has issues and it can lead you astray if you don't understand what it is doing, but there isn't anything better. As the article points out the "proper" traceroute from the RFC was never implemented. Some of the other complaints like if you traceroute too much it might bog down the CPU on the routers seems just petty.
About all the article can say is that you'll probably just find out that the problem is in some other network and fixing other people's networks is impossible so don't even try, which is a depressingly defeatist attitude.
> Some of the other complaints like if you traceroute too much it might bog down the CPU on the routers seems just petty.
This part is actually important, not a petty thing. Not because we should care (much) about cpu usage on routers; packet routing is (or should be) 100% hardware offloaded and CPU usage doesn't matter for the main business of a router. But, it's important to be aware that sending ICMP reports is CPU limited and routers have limited CPU resources so there are limits on the reports that will be sent. Then you need to know that measured loss at one hop may indicate loss from that hop or a busy router.
There's probably many better ways to present this information, but if the point is to argue that when things don't work, the best thing to do is wait a week and let things sort themselves out... Well I don't like that either.
About all the article can say is that you'll probably just find out that the problem is in some other network and fixing other people's networks is impossible so don't even try, which is a depressingly defeatist attitude.