Dan McKinley has an interesting site based around a talk of his in which he extorts the value in choosing boring technology. He fully admits that this is something of a click-baity title, what he is really talking about is old known technology as opposed to new unknown technology. Having read the site I feel that it really has two separate points. The first point is about old, boring technology as opposed to new/exciting technology. The second point is about trading-off pain now for pain later.
So the first point is that often new technology specifically addresses complaints or pain-points about older technology. Of course sometimes it is worth betting on the new and exciting technology in the hope of elminating those pain points. His point is that if you choose the old (boring) technology then you know what the pain points are, and you can decide if your current project is likely to really suffer from that or not. With new exciting technology it may well fix those pain points, but the chances are it will bring new (and possibly exciting) pain points, but you do not know what those pain points are. This situation is described in Sarah Mei's article Why you should never use MongoDB if you can get past the emotive title. The point there is that although the document-based databases solved some of the pain points associated with relational databases, there were new pain points that were not fully appreciated at the start of the project. If you do not know what the pain points are, you aren't going to be able to accurately evaluate how the technology will work for you in your current project.
The second point is regarding the trade-off of paying some pain now versus paying some pain later. Here he is basically talking about adding a dependency upon some technology to your stack. The pain you avoid now is re-implenting using your current stack, whatever benefit that technology provides you with. The pain that you are potentially setting yourself up for later on is more integration between the technologies in your stack. He gives a great example that if your stack already included the Python programming language you would be almost certain never to include Ruby into the stack, even if it solved some problem right now. That is because later you will know that at some point you will have to call some Ruby from Python code, or somehow write some integration code. You want to have your data structures represented in as few languages as possible because it's basically enforced duplication, that is bound to get out of sync eventually, so everyone knows to use as few programming languages as possible. But you should apply that thinking to other technologies in your stack. Dan McKinley provides an example from experience of choosing between mem-cached and redis, where redis was the better choice for the task at hand, but mem-cached was already being used in the project. Hence some pain at the outset to workaround the limitation of mem-cached (it is ephemeral), saved a lot of work later because nobody had to maintain redis.
Of course it is a trade-off, pain now vs pain later, so just because it's usually harder to pay with the pain now, does not mean that is always the wrong choice. Just as sometimes taking on some technological debt now can be the right choice, choosing to pay the pain later may well be the correct choice. The point is that to notice that you're far more likely too erroneously choose to pay the pain later than you are to erroneously choose to pay the pain now. In particular, you're far less likely to acknowledge that there will be pain to pay later. So you should try to bear this in mind when deciding whether or not to add a new technology to your stack.