My reading of that statement was not that good engineers won't use the right tool for the job, but rather will use the best they can, and deal with imperfections. Almost as a rephrasing of the old adage: "'Tis a poor carpenter that blames his tools".
There are often factors outside the control of the engineers that dictate certain things that can and cannot be used. Sometimes they are political and sometimes they are more technical. The ability to get things done in spite of externally imposed limitations is something that should be praised. Even something as simple as the choice of platform can be a cause of not using the ideal solution... say there are only X, Y and Z allowed languages - using the cool library for language W is off the table, even though it is highly regarded as the correct and best solution.
Excellent point.
I see the opposite as a problem - not being aware of standard solutions for tools, and reinventing the wheel yet again without even bothering to go look for something that might exist already. Praising this 'macgyver' skill reinforces in people's minds that it's perfectly fine (perhaps desirable) to "roll your own" all the time. The extra couple hours or days you spend up front understanding tools that tens of thousands of other people already know will pay off down the line when you hit configuration, scaling, performance, security or other problems vs your home grown 'solution'.
This has continually been something I've run in to the past few years, and it reminds me of my own 'roll your own' justifications from 10-15 years ago. The only defenses I have are back then there was far less available open source tools (or even closed source) for many of the problem domains I hit back in the mid 90s. Today that's far less of an issue in most situations, and I'm far more sensitive to the maintenance burden imposed by a 'roll your own' mindset (because I've had to maintain my own code from 10 years ago!).
It's one thing if the primary options are off the table due to budgetary issues (hit me recently as well), but in most cases I find it's people not being aware (and not researching) to see if industry standard options exist.