A more charitable reading would be "don't use complex tools to solve simple problems". That's a fine piece of advice when your problems are simple. Simple problems rarely stay that way. Most of these articles lamenting the state of front end development make a similar concession:
If I see a section on my app that is really hard to with Pjax/Turbolinks and jQuery, I’ll bring in a library/framework like Vue.js, React, Angular. All good choices for doing really complex forms(although I find Angular to be the best at this), with a ton of conditional validation. You know what though, these are the outliers in my experience, not the norm.
Sure, adding a form to your front page can be done with a couple lines of vanilla javascript. But you suffer the cost of a framework or library at the start of a project because it pays dividends at the end of a project. When you have to filter a list of ten thousand items as the user types, you'll probably wish you could use virtual DOM diffing. When you have to step through a series of ten asynchronous requests before updating a view, you'll probably wish you could use async/await. When your site takes five seconds to load over 3G because of your single monolithic codebase, you'll probably wish you could tree-shake your dependencies. The tools mocked by the author have real uses, he just refuses to see them.
That being said, it's not all bad. System.js/JSPM has improved my front-end workflow quite a bit and the SPAs I've made with the new workflow have been both stable, compatible and fast (very few end user complaints, lots of praise, quick development). So while some things have become convoluted, not everything is dire.
With clojurescript it was a no brainer since the effort to make it reactive was functionally 0 compared to default hiccup data structures.
