I too read that series!
And I learned to like ES6 from it. I've had to since JS is the de-facto language where I presently work. And I immediately recognized the functional bits that turned out, for me, to be the best parts: functors, monads, currying and the like.
However the problem I've found is that as our code scales up in size and sophistication it requires greater mental effort and discipline from the team to maintain consistency and manage complexity. ES6+, for better or worse, is a kitchen sink language. The hard part is getting everyone to agree on the subset to use and enforcing standards.
At first I thought this was a wonderful language for teaching FP in: it's forgiving, people can learn concepts as they go and put them into practice right away without having to go whole-hog on FP. This works for senior developers for the most part. However for junior developers, I've found, it can add to the confusion.
And if I'm reading the tea-leaves right it seems like Microsoft and Facebook have been having the same issues with large Javascript projects. Why else build tools to help manage the complexity if the language already provides them? It seems like there's a good language buried in Javascript, somewhere, but the lack of a sound-type system and a plethora of historical baggage obscures it.
All in all learning Javascript is worth it if only access to an ecosystem of highly-active development is valuable. It can be a pleasure to write... but my advice today would be to learn a pure FP language first and come back to Javascript if you need to.