It has taken me decades to confront this thinking in myself and even now, at times, I run into this logic. It's automatic thinking.
I like the article. You have to be 100% crystal clear that you are interested in the delivery of the finished concept and not the tools you used to build it.
Choose what works.
I've had "1h learning" as a daily task for many years now, it's how I transitioned from PHP to Node. Shiny and hot, yes, but more importantly it's one language across all the work I do, and that saves me _tremendous_ amounts of time from when I was on PHP. That was a worth-while investment. Now I'm using Angular while React is getting hot. I'm not convinced that'll boost my productivity substantially, but I have that 1h/d to learn so why not? If it turns out to slow down my productivity compared to my Angular expertise, then I'll veer that 1h/d towards something else instead (VR + Unity is sounding super interesting, or maybe I'll explore this functional programming stuff everyone's raving about).
It's becoming a bit counterproductive. I wrote a post about this because of how often I've come across it that's worth reading: http://room4debate.com/debate/tech-stacks-frameworks-languag....
I've got presales, and none of those customers give a shit about the platform.
Seriously it is probably a good idea to look a little at new things and possibly try one out and later switch every few years. I could be after 5 years or after 10 years but you can probably find things that helps a lot with some projects. Regarding the unknown one might want to differentieate between things you don't know and things almost no one knows about (ie very new things), the latter aren't really battle tested yet but the former might be.
Choose whatever takes you to MVP the quickest. Avoid the #beliebers in the echochamber[like this one!]. Choose something that you're familiar with, and probably aren't immersed deep enough yet. So that there is still ground to cover. Usually there is always much to learn.
Focus must be on the MVP and not on the quality of the framework or the hipness of stack. Those things are unimportant until you're ready to hire. Once a bit more stable then play around. Contribute into the system. Push it forward. Avoid stagnation. Have beer. :)