Even monoliths are dealing with outbound network calls.

I assume it depends on your current solution, but for a new project, I find that setting up instrumentation and pushing traces to Zipkin or Jaeger is very straightforward, at least on the JVM. Out of the box I can see the overhead on top of DB queries and plain HTTP calls. And if some bit of internal logic is particularly time consuming, I can add a custom span in two lines of code and figure out what's going on. There are of course other ways to achieve the same thing, but the experience feels nicer.

Tracing term is kind of overloaded. In this article its used not as _distributed tracing_, but as _instrumenting_. E.g., Linux's trace points, or any other tools such dtrace, strace and so on. So it doesn't relate to systems design decisions.

if you've got an IT ecosystem with enough monoliths / macroservices calling each other, being able to trace across service boundaries is still pretty useful