Nowadays I only consider switching front-end frameworks if there is a substantial conceptual improvement. React did this for me due to its uni-directional dataflow and component-based architecture. There is nothing new here conceptually.
I find that this is the most sane tactic as well. If you just limit yourself to frameworks with conceptual improvements (that _also_ show at least signs of substantial adoption, and preferably already are widely adopted), then the churn really is not that high. It used to be jQuery, then Angular around 2012, and now React. That's perfectly doable in terms of keeping up, at least as long as you're an actual front-end developer rather than someone who also has to do the front-end.
(And perhaps it's less so when you're older and I'm one of those darned millenials now, but I wouldn't know.)
In another comment I mention that the biggest conceptual improvement that Marko offers is async and streaming rendering. Async changes how you think about passing data to your view (you start rendering immediately and you can retrieve backend data asynchronously to start rendering parts of the page asynchronously). Also, Marko is not tightly coupled to a VDOM (while React is) and because Marko is not tightly coupled to VDOM rendering we can achieve significantly better performance (sometimes over an oder magnitude faster than React on the server) and this absolutely can make a difference. The slowness of React (and the sync rendering) were huge blockers from the very beginning when we considered using React at eBay. --Marko author
I feel the same way. It's a huge investment picking up an entirely new tech stack, and I'm not throwing that investment away every bloody year.
I feel like React has hit that tipping point that Rails did several years ago: it's no longer cool but it's still incredibly productive, and literally every new hip
library that is currently flavor of the month is modeled after it in some way.