One of jQuery's most popular, and arguably most useful, features is one of the biggest reasons it's a pain to refactor jQuery out of an application: the lack of distinction between a selection returning a single element or a set of elements.
This wouldn't be a problem if document.querySelectorAll returned an Array, but that'd be far too programmer-friendly for the DOM Spec folks. No, we need to return a DOMNodeList, which duck-types only the most basic of Array functions. If you need an actual ECMA Array like a normal person (to map/filter/forEach/etc. over), you'll have to Array.from() that DOMNodeList, which is both code and memory overhead since nothing in DOM-land runs on streams as it would if DOM were a Node library.
But that's fine - just do a single-selector and be done, right? Wrong. Because modern web developers have been fed the "IDs are bad, classes for everything!" dog food, it's impossible to easily determine, looking at some source code, whether any selector (jQuery or DOM) is going to return one or multiple DOM nodes. So now, I need to go in by hand and test every jQuery selector in my application and see if it's returning one or multiple DOM nodes, so I know whether to refactor this to a querySelector or querySelectorAll + Array overhead.
I'm starting to think frontend web development is a self-fulfilling prophecy. There's a limited selection of skilled JS engineers because we don't feel like dealing with this shit, but since nobody deals with it, bad ideas propagate and prosper, which leads further down the rabbit hole and drags the "average" for frontend developer skill even further down as we go.