This basically sums up things I've said over the years and thought about. You and your team have a problem to solve. Anything that gets in the way of solving that problem is the wrong solution. Learning a bunch of new tech looking for a silver bullet or because it is 'kewl' is the wrong answer. There is the learning curve to consider as well as the instability inherent in a new tool set which needs to be understood when making these decisions.
What is even more distressing is when you see bad ideas return like bad pennies, network databases are now graph databases for example. ACID compliance sacrificed for 'speed'. Having to write you own threading management code. Those immediately pop into my mind. Sure, there may be some short term gains but what about 5 years from now? After a huge investment throwing something away and replacing it becomes difficult and expensive. I am looking for the citation but I once heard that the maintenance costs of software far outstrip development costs by about 10 to one.
My advice is to first learn the problem domain which includes keeping a long term view in mind, then pick the tool set with a bias towards the tired and true workhorses. Spend less time thinking about your tools and more time solving the actual problem.