Rather than everyone reimplementing their own utility libraries, here we have one central library already cached by most areas of the internet, being maintained by some of the brightest developers in JS, and provided free of charge.
If your site permits, you are probably using the Google CDN hosted version of jQuery. If not, you should. If you can't, then your users can handle some 80kb one time load for a tremendous reduction in development time and increased consistency between browsers (let's be honest, cross-browser testing is a pain and we avoid it as much as possible).
So many people think that by using jQuery your code must immediately be bad. Spaghetti code is code with bad structure, jQuery does not enforce any structure so any bad code that includes jQuery is not the library's fault. I also believe (I don't have evidence for this) that this thought tends to occur amongst people who have learned front-end development using jQuery because it was very accessible, and then moved on to something else, and then looking back at their old, cruddy code developed negative feelings towards jQuery itself. jQuery doesn't care how you structure your code; you can use jQuery (admittedly with some difficulty) with Angular, Backbone, or any other popular framework. But you can't use Angular with Backbone. Arguments against jQuery that attack poor code / structure / "prettyness" are completely misrepresenting jQuery as a library.
In that same vain, jQuery is not slow. How you use jQuery, just like how you write your vanilla JS, is what determines performance. Some jsperfs show jQuery being slower than vanilla JS or lodash/underscore, but that's because jQuery is checking for many more things. You don't have to use jQuery if you know how to improve critical code, and you really shouldn't. However, it allows for you to write code quickly, without much complex thought for validating against edge cases at a very negligible performance reduction.