I can only comment on Backbone.js, which as part of a 10-person team I'm currently using for a medium-sized single-page ('enterprisey') web application on the front-end. I would also say that the app is pretty much a read-only experience in that 99% of server requests are simple GET requests. There is a fair amount of data filtering and a bit of complexity in the view (dragging, scrolling, etc) which made us realise that using jQuery and a bunch of plugins alone would result in a big sloppy mess.
Here are some pros and cons that we have come across in the course of the project so far. These may not affect everyone, of course, and there are bound to be others.
Lack of UI dependency
Backbone uses jQuery or Zepto.js in the view layer if they are available, but it is certainly not dependent on them. Others have had success using MooTools for example. Its only other dependency is underscore.js which is maintained by the same developer (Jeremy Ashkenas).
Model source agnostic
Initially our data is sourced from our back-end application, but we're planning on making use of localStorage for offline usage, and looking at other solutions for performance on mobile. Backbone supports any mechanism you like for RESTful operations using Backbone.sync(). There is already a localStorage adapter for Backbone.js, for example.
Backbone passes messages between the models, controllers and views using built-in event types, and also provides a mechanism for you to pass your own custom events around. These are very useful for avoiding tight coupling in your code, but again it's a feature that is not unique to Backbone.
Backbone is opinionated enough about how to structure your app that it will make some structural decisions for you. However, you'll still spend plenty of time working out exactly what objects you need to create and how they are related, particularly if you have a complex UI with a lot of varying states.
In our previous project work, we relied on a combination of QUnit, Canoo WebTest and Selenium for our tests, which were heavily weighted towards the functional end of the testing spectrum. They were slow, brittle and a pain to maintain. Unit tests were lacking because we simply lacked the units to test effectively.
Backbone.js insists on the creation of sensible units, making unit testing that much easier. We currently have a suite of 100+ Jasmine BDD unit specs that run in under 0.3 seconds. These specs test all aspects of the Backbone app, including server requests and view rendering. The speed they run at is down to the use of Sinon.JS fake servers and fake timers. I've written a series of blog posts on how to test Backbone.js apps with Jasmine and Sinon if you're interested.
We still use functional tests, but our unit test suite catches most bugs.
Backbone.js only allows a single controller to specify URL routes per page. I personally found this slightly limiting having used Sammy.js, which allows you to create as many Sammy 'applications' as you like, each with their own set of route handlers.
This gives you the ability to have each part of a page be in charge of its own responses to a set of routes, another feature that allows code decoupling and improves testability. You can get round it by having your interested objects bind to Backbone's built-in route events, but the route events are only fired for routes that are specified in the single controller. In our application, the controller is really just a route configuration tool and not much else.
This is currently the weakest part of Backbone in my opinion. History management and route dispatching has a major bug in Internet Explorer 6/7, and there is currently no support for the HTML5 history API (pushState, etc.) Dion Almaer has apparently successfully integrated Backbone.js with Benjamin Lupton's more complete history.js library on the FunctionSource site which I am planning to look into.
There are the usual problems with being a relatively early adopter, as derek has already mentioned, in that for every Backbone.js tutorial out there, there is a different approach for structuring your app. For what it's worth, we found a few things early on: Too many Backbone 'classes' is better than too few; use events or pubsub wherever you can; keep as much code out of the controller as possible; and rigorously remove tight coupling.
Nesting / composition
This is perhaps not a con per se, but coming up with an effective object model for your Backbone app can be a challenge. I advise you to read the Nested Models & Collections section in the Backbone docs. You will be doing a lot of this for anything but the most simple apps.
If you've had any experience of UI systems that make heavy use of composition and/or delegation (I'm thinking along the lines of ActionScript 3 and iOS apps here) then you'll feel pretty comfortable coming up with an object schema for your Backbone app.