That's not what I mean, unless you assume that you have no control over other elements of the process.

To torture the woodworking analogy, your assumption is that the carpenter has no control over ripping the boards. In some instances that may very well be the case, but there will also the instances where the carpenter does have influence over creating the boards, or even wholesale control over ripping them. In those cases, using a planer to fix poorly ripped boards may not be the best approach.

How often do you actually have control over the entire process of anything? Even website development, unless you’re going to handle raw TCP sockets, you’re going to build on top of someone else’s tools one way or another. And in a business world, you almost always have to deal with other teams, other people, other priorities. Even when you run a company, not all of your employees and partners can always do things exactly the way you want. Having a flexible tool that works in the real world on real world data on top of real world processes is incredibly valuable.

I think you're engaging in some dichotomous thinking. I'm not making the claim you'd have to have "control over the entire process". What I'm cautioning against is just looking to the tail end of a process and assuming that's where you need to add leverage.

Even in your examples, yes, you have to work with other teams. "Control" doesn't mean you have dictatorial control. But it does sometimes mean you have build relationships, leverage what you can, and explain the value to those that do have some modicum of control. The idea that we just throw our hands up and jump to workarounds can work, but it's often an excuse for taking the short-term easy at the expense of a better long-term solution. Even when you're using tools as a workaround, you're surrendering control to those tools/developers.