Open the network tab on a stock Sitefinity site and you will see jQuery come down twice. One copy is the version Sitefinity itself runs on. The other is an older copy bundled with the Telerik RadControls, and you can turn that one off if you never touch RadControls.
Two copies of jQuery. Every Sitefinity developer notices it eventually, and a good number of them have decided it is the root of all evil. Any script error, anywhere on the page, gets pinned on the double load. It is the jQuery conflict, Telerik needs to fix it. That has been the received wisdom for years and it is wrong.
The RadControls copy does not fight your copy because it never claims the global. Telerik registers theirs as $telerik.$ and runs it in noConflict mode. noConflict exists for exactly this: it hands $ and jQuery back to whoever wants them so two versions can share a page and never collide. You can call into both on the same site, in the same handler, and neither one knows the other is there.
So when your script throws, the double load is the lazy answer, not the real one. Go look at what you actually loaded. A <script> tag in your masterpage head pulling one version while a control quietly emits another through a ResourcesLink. Or a plugin that bound itself to the wrong $ before the version it needed was on the page.
Blaming the two jQueries feels good because it points the finger at Telerik instead of your own load order. The order is almost always the actual bug.