This is like attempting to counter a proposed rule/guideline of program design by saying, "You should always use the best tool for the job." While technically true, it doesn't say anything about what makes a tool suitable for a job. Similarly here, maybe there are common patterns/rules followed by libraries that "do their job well and don't get in the way of using other tools." But dismissing any proposed rule just cuts off the conversation without giving a reason. The details really do matter.
I think what bothers me most about this way of thinking (which seems common here and elsewhere in the industry) is that it provides a veneer of credibility to bad developers who don't want to think about design and would prefer to just wing it.
Be pragmatic.. use the best tool at your disposal that suits your larger environment. If the company you work for is all .Net, they bringing in a small utility app that uses Python is a pretty big risk. The same can be said for most things in a given environment.
That said, I gave node a beachhead into a number of projects, because they were web applications and it made sense to do so. Even if not running on node, having the client-side bits using node tools made sense.
It really just depends. All in all, there are at least a dozen options for any given problem, and 4 out of 5 times the closest thing to what you are already doing is likely the right answer.
I think what bothers me most about this way of thinking (which seems common here and elsewhere in the industry) is that it provides a veneer of credibility to bad developers who don't want to think about design and would prefer to just wing it.