Each of the frameworks provides you two types of code reuse:
Alright, jQuery takes care of some boilerplates as well, but these boilerplates are usually DOM/Ajax oriented. There’s nothing in the core of jQuery, which provides you two-way data-binding, for example. When you develop Single-Page web application you see that there are a lot of cases where you need to explicitly set the content of given DOM elements, or recompile template when some data changes. Frameworks like Ember.js and AngularJS do this for you!
Reuse of your own code
You have out-of-the-box Separation of Concerns. In each MV* framework you have Model and View. They both have their own responsibilities – the model is responsible for encapsulating your domain specific models (in case of twitter – Tweet, User), on the other hand the view is responsible for showing the model (and eventually handling events, it depends on the framework). This means that your model is not coupled with its representation and eventually can be easily reuse it in different project. In this type of code reuse, usually you cannot reuse as much source code, across your projects, as in the case of boilerplates but you still have it, without any extra work.
Level of abstraction
Each framework provides you a higher level of abstraction, which allows you to handle more complex applications. Try to build something large without any framework and you will find yourself dividing the code into different coherent modules, trying to decouple them as much as possible. Probably you will end up with something like this module architecture. Of course, if you don’t follow any guidelines for good OO design (explicitly or implicitly), it is very likely to end up with large bunch of spaghetti.
Most of the MV* frameworks are build with testing in mind. For example, in AngularJS you have Dependency Injection, which allows you to mock given service quite easily. You don’t need monkey patching anymore! One of the drawbacks of the module architecture, which was referred above, is its hard testability.
or the module pattern
or constructor function
Why not to create a custom framework and build my applications with it? First, you already have pretty good solutions, which are build by great developers and tested by hundreds others. Second, if your team is dynamic you will increase the learning curve for the new developers who are joining your team. Each of them should spend time studying your problem domain, your proprietary framework and your existing code base.