There is of course the other option of not using any of them and programming custom things in javascript. I'm not sure if this takes longer or not - I haven't used any of the above libraries - but I think you get a more satisfactory result.
DOM manipulation is pretty simple with the javascript dom functions, as is animation, although it depends on how custom you need it, and how much you're worried about speed/bloat/etc
I disagree. Achieving smooth animation without a library is extremely difficult. If you look at what the modern libraries actually do you'll see that they have two features which are tricky to implement from scratch: frame rate limiting and easing. Frame rate limiting means that if you are running lots of complex animations at once the libraries will drop frames to ensure that all animations complete in the allocated time. Easing gives you a pleasing speed-up / slow-down effect during your animation which makes them look far more natural. This is a fair amount more complicated than simple animations set up just using setTimeout.
Of course, you can roll that stuff yourself - but why duplicate all of that effort?
Also, DOM manipulation with the regular DOM is amazingly inconvenient when compared to manipulation using a library such as jQuery. The DOM is a pretty verbose API with a lot of weird quirks (removing a node: "theNode.parentNode.removeChild(theNode)") - jQuery provides a much more sensible API, which in turn means that I find myself using DOM manipulation a lot more since it isn't such a pain to do.
Just track the actual number of frames an animation has taken so far and the number of frames it needs to take to complete in the time taken. For bonus points re-average your framerate each time an animation ends by keeping track of the number of frames an animation actually was able to take.
And to do 'easing' as you call it, you could just use sin/cos, or a small lookup table.
The main reason to duplicate effort is to firstly learn how these things work, and secondly to get a better solution matched more optimally to your use case.
I personally like the DOM... theNode.parentNode.removeChild(theNode) makes quite a lot of sense. But it's probably a matter of taste that one.
because using any library is always going to be less optimal than a custom solution.
When I started learning js I just decided it would be worth more to learn js, rather than any library. Now I know js there seems little benefit on learning one of the js libs.
Of course this is all just my personal opinion and experience.
because using any library is always going to be less optimal than a custom solution
I strongly disagree. The library authors, and fellow users, have discovered and worked-around browser and Javascript gotchas and performance bottlenecks that it could take you years of custom work to independently discover.
Not really true. And you can always look at the source of libraries if there do happen to be some gotchas or bottlenecks (I think the number of these is really overstated).
The issue is, they make general libraries that cover hundreds of use cases. Because they cover that many, they are very general, and useful to lots of people, but they are non-optimal. They have extra things you won't need. They have extra arguments to functions you don't need. Bloat.
I fall back on raw JavaScript DOM manipulation for performance-critical stuff, which is a decent-sized chunk when you're doing arcade games in JavaScript. You can get decent results, but I wouldn't recommend it unless you really are performance-constrained. You end up spending a lot more time than you'd like on browser-specific bugs. If you're just trying to put up a UI to respond to your user's clicks, you're much better off with a lightweight X-platform library like JQuery or Base2.
DOM manipulation is pretty simple with the javascript dom functions, as is animation, although it depends on how custom you need it, and how much you're worried about speed/bloat/etc