Ok, so now I've got your attention you eager beaver SharePoint End Users...Power Users...etc. I thought I'd just put a few things out there from the other side of the fence!
So there's lots of hype around jQuery and SharePoint on various resources such as EndUserSharePoint.com and some of my other personal SharePoint Developer heroes: Joel Oleson, Jan Tielens, Waldek Mastykarz, Nick Swan, Paul Grenier (aka AutoSponge) and David Kitchen. There is a great summary post on jQuery here by Vedant Kulshreshtha.
To summarise, jQuery is mainly used to make SharePoint User Interface "useable" as Mark Miller put it in Joel's comments. He does put a caveat in terms of "it having its place".
The Cons
Avoiding Development
jQuery is a serious band aid in terms of avoiding modifying the User Interface via the correct Microsoft supported approach: Solution Packges, Features, Master Pages, Page Layouts and CSS properly. If you click on a lot of the links above you'll notice most is to tweak how SharePoint renders the out of the box page elements. This can all be done by development approach as well with a lot more control around it (versioning, deployment, performance, extensibility etc.).
Upgrade Path
The benefit of modifying the User Interface via the development approach is that you are extending SharePoint's User Interface control elements rather than adding an extra layer between SharePoint's rendering and the User viewing seeing it rendered. By adding this extra layer using jQuery to hack at what would be rendered you are introducing dependencies in terms of what you expect SharePoint to render. This will become an issue when you run any service packs on the SharePoint farm because there is no guarantee that things will stay the same between version!
Losing Control - "all or nothing"
This brings me on to my next point. Most of the examples displayed encourage users to place jQuery into Content Editor Web Parts within Web Part Zones. This basically means that anyone with access to a Page can add this web part, paste in the jQuery code and save it.
In short, controlling who can and cannot add jQuery is going to be a problem. SharePoint does not have the ability out of the box to block certain code blocks such as <script> from being used within Content Editor Web Parts or any Rich Text Editor element on a page for that matter.
Breaking stuff
It is also worth pointing out that if "power users" write crap code and don't test it properly, that they will break the JavaScript for that page which could stop other scripts from loading up properly. This could cause even more useability problems. Even worse, imagine if they write recursive methods or massive loops or worse still find some code that calls the web services and puts huge load on SharePoint servers. The worst case scenarios here are endless!
Enforcing Branding
jQuery basically gives "power users" the ability to break the branding that SharePoint is meant to put back into the control of the corporation. It's one of the selling points of the Platform, and now we're encouraging them to hack around the efforts of consistency with Master Pages and Page Layouts.
Maintenance
As a scenario, imagine two years down the line when there has been multiple "power users" who have dabbled with jQuery and cut and paste stuff from all these resources out there to make their SharePoint User Interface "useable". It'll be an absolute nightmare!
The other issue with this is that the scripts are being put straight into the Content Editor Web Part. There is no versioning in these web parts and I can't see anybody trying to enforce that jQuery scripts be put in source control first by Power Users before being deployed to Production as it'll be deemed as content.
Business Logic locked in client side
I've also seen jQuery being used for Business Logic, for example, domain validation of List Item columns in forms. This again can lead to business logic being locked into client side code with no versioning or unit testing! The best way forward with regards to this is calling off to Web Services...but that would require Development. So why not do it in development in the first place?
Testability
jQuery is a client side script that is executed in the browser. The only real way to test this would be to record User Interface scripts and re-run them each time. Again, this is a huge overhead...even more so if this is done manually. To put this into perspective...how would you test it's all operational when you've completed the next SharePoint update where the user interface has changed?
Debugging
I'm actually quite shocked how jQuery has entered the mainstream like this. It wasn't that long ago that JavaScript was the devil and that it was just all so hard to debug! There are some great tools around to help you these days with this, but just bear in mind that sometimes it is a nightmare to see what is going on. So if developers aren't that happy with it (in general) how are "power users" going to cope?
Accessibility
Browsers have come along way with regards to JavaScript support and jQuery as a framework has done a great job of getting coverage across most JavaScript engines. Most Power Users who are playing with jQuery are in an Intranet environment which is typically controlled by a SOE that includes the latest update of Internet Explorer 7.0.
It is worth highlighting, for those not in this scenario to be aware that it is not going to be a reality if they have JavaScript disabled. This is especially so for Internet facing web sites where you can't control the end users browser.
The Pros
Open Source
As a framework, you can't go wrong with jQuery. It's becoming the mainstream JavaScript framework of choice across many solutions these days. I appreciate that there is a lot of buzz across the whole IT world around jQuery for numerous reasons such as Microsoft taking it up for SharePoint 14 even though its an open source project originally created by John Resig (who currently works at Mozilla).
Easy to Use
The jQuery framework is a lot easier to read and understand compared to other frameworks out there. It is also extremely light-weight and easy to snap into a page (almost too easy).
Community
The jQuery community (see Joel's post) is growing at a huge rate because of the uptake by major platforms and also because the open source community just knows how to create buzz around products.
Web Services calls to avoid postbacks
Everyone hates ASP.NET/SharePoint Postbacks with a vengeance, the ability to refresh sections of the page without refreshing the entire screen is a godsend from a usability point of view.
Ok, so I'm off my soap box. But I feel that it is my duty as a member of the SharePoint community to point out the risks of jQuery in SharePoint implementations! Giving this much control to "power users" scares the sh*t out of me or as my Perth metal lover Paul Culmsee would say "leads to a wicked problem".
I'm all for "power users" to control content within the platform...I just don't see writing jQuery as something they should control!