Same for programming. The more you are aware of, the better able you are to chose the better way of proceeding on a project.
I'm probably scarred though, I work with people who believe that c# and sql server can solve all the world's programming problems. (I like c# and sql server, but they aren't always the best solution for a given problem)
This is a part of the problem. "The right tool for the job" has become an end in itself, rather than a means to an end. People spend so much time trying to develop more than a superficial understanding of a vast array of languages and frameworks, simply so they can say they are using the "right" tool for the job (perhaps so their future "show HN" post can be sexy). The right tool should always be understood as successfully executing your project as the goal. Sometimes the right tool is simply the one that you or your team has expertise with, or has a deep body of experience built up on StackOverflow. The "right" tool in absolute terms is completely meaningless. Often times it seems like people forget this.
For our purposes, there are "better" tools available than those that were chosen. A pain that we're feeling now, a couple of years on, as we start to migrate a live application to those other platforms. That's a big loss of productivity for us because choices were made to use tools that were familiar instead of figuring out if they actual made the most sense.