> While I imagine that variations of TSP occur for logistics companies, it also occurs in problems where "solve once, use many times" applies, such as electronics design.

That is true, but it's the same that I was saying (and it's why I included the many variations at the end of the statement). Basically if you have to do something once and for all, then of course you can just solve it in some sort of educated brute force and you are probably fine. It's when you have to continuously adapt the solution to a changing network that you need to be fast, and in that case you need to consider that the computation time kinda together with the traveling time (of course it's more complicated than that and you need to include the cost advantages etc.).

I agree with the graph comment, even if we are growing in the amount of data to deal with those graphs, so there will be often more and more need of simplified or shortened solutions if you want them to run in an app on a phone, or on a server (but for a million requests).