No, it's not awful advice, but your advice is pretty bad. MTR is a great tool for certain situations, most notably internal troubleshooting as an initial sanity check, but it frequently fails to provide meaningful insights into issues beyond many local networks for exactly the reasons I outlined above. Attempting to appeal to your experience here fails, as mine exceeds yours.
If you're not monitoring services and you don't have access to internal stats for the server (frequently VM these days) hosting the service, including at a minimum memory, disk IO, and CPU utilization, you're poorly equipped to explain most real world outages. When dealing with production environments more complicated than Bob's Blog that gets 100 hits a day, countless examples abound for cases where things in a given network path, including the destination, will happily respond to ICMP while the services you actually care about are flailing about while a server OOMs, runs out of disk on a critical volume, suffers from a badly executed code push from some half ass dev team that takes out a web app, poorly constructed SQL queries take minutes to return data, a marketing campaign succeeds but nobody bothered to tell IT that resources should be scaled up to support increased traffic, etc. Do you actually have any experience with that level of monitoring? Your post suggests you do not, and if I were your employer I'd can you as soon as I discovered that fact. You're espousing an overly simplistic and unreliable means of monitoring IT environments, but please feel free to continue your willful ignorance (read: stupidity) so long as you don't mislead others.