This is kind of a cop-out, but I am constantly surprising coworkers with the (I thought simple!) things that I do with relatively old-school JS. I think if you're just starting out on a project -- any project, any skill level -- then your biggest obstacle is your own inertia, your tendency to evaluate options for how you might solve the problem, rather than just plunging right in and saying "I am going to code
something, it may not be the right thing, but I am going to try to write this little function which does this little thing." (I once heard some conference speaker say something to the effect of "I found it very hard to floss until my dentist said 'hey, if you don't have time to floss between all of your teeth, please still try to floss just one.' Suddenly I'm at the mirror like, 'I don't wanna take that time to floss all my teeth... oh well, I'll floss just one to make my dentist happy... oh, and I might as well do another, and another..."). The hardest thing is to get started, which paradoxically can begin just about anywhere you want. You just have to choose something and do it. So a lot of this "what framework am I going to learn and use?" stuff gets in the way of this and slows you down from tackling this hardest-problem-that-should-be-a-non-issue. Just start with low-level JS and begin building, then let your pain in doing so guide your further choices.
Because low-level JS sucks, of course. It sucks that the DOM specifies that each node in HTML has a property .childNodes but the object that resides in that property is not an array with a .forEach() method so you find yourself either doing `Array.prototype.slice.call(x.childNodes, 0)` (in ES5, for compatibility), or `[... x.childNodes]` (in ES6 because it's prettier and more obvious what you're going for). And it sucks that HTML tables don't come with any built-in sorting mechanisms, and it sucks to be dealing with XMLHttpRequests directly. That's why these frameworks build on top of those things.
But I really think that if you're starting out, you should start out with this sucky stuff and then choose your framework based on what you learn about your pain points, rather than the other way around. If you find yourself needing to support older browsers then you will learn these cross-compilation tools; if you find yourself eventually turning it into a RESTful API written Node.js then you'll probably be OK with just ES6. Or if you find yourself writing similar sortable table widgets for the third time, you start googling "has some framework already solved this stuff?" and you eventually stumble upon the search "grid component" which will get you checking out either Vue.js, React (though you'll quickly realize that it's not native to React, there are several options there), and Ext.js, all of which have fine grid components that you might start using. Now you're doing a short research project to incorporate those things into your present workflow, which is much better than doing a long research project to decide which one of these things will be your Firm Foundation For All Things To Be Built Here.
The other huge thing about knowing plain JS is that you can start by messing with other peoples' web sites; just Ctrl-Shift-J on whatever page you happen to be on, "how would I add a little button that would replace all instances of the name 'Paul Graham' on this comments thread with the phrase 'my little pony'...? I think it would be hilarious if all these techies were talking about ponies instead."