I think it really depends on how you structure your HTML as well; having tortured myself into learning Angular has really helped with understanding how to think about data structures as opposed to strict DOM elements and this has carried over to how I write javascript nowadays.
One thing that I will mention is that I have worked really hard to not use jQuery over the last year, so my preferences may not be shared by you. I guess it depends on what is quicker and easier to maintain for you.
That was one of the pains the Fetch API cured for me. The syntax and overall concept is just so much nicer.
I was using Nanoajax library before that. It's great (and light, 620 bytes gzipped), but I moved almost completely to Fetch as soon as i started getting used to Promises more.
I guess libs like these and maybe even the Fetch in current browsers were somehow inspired by jQuery's $.ajax…
If download size is at all an issue, jQuery is the first thing to go. I have a tiny collection of helper functions that make 'plain js' almost as simple as jQuery in most cases. Almost.
For example, at the very least I'll have a '$' helper function that makes document.querySelector(All) simpler/quicker to use, and I use a helper function for events to make it a bit more like $(<selector>).on().
But considering the fact that I have quite a few projects where the client will upload some huge image for the home slideshow or where there's no time or incentive to do any lazy loading of images, jQuery is often still the pragmatic solution. Especially when other devs need to deal with the project at a later stage.
Besides, 400k of (blocking) JavaScript can be the difference between the site loading quickly on mobile and the user giving up.