Hey Tim, so I am going to try my best here. It's Friday, bear with me.
Us engineers here at Dollar Shave Club have come to determine that Angular really, really excels at user interface scripting. It's not as good as others at model operations like create/read/update/destroy. But it's really, really good at UI.
It removes all of the tedious $('.my-button').on('click', function(){}) that one typically does when building a simple jQuery/JS scripted site. Event handlers, global variables that manage state of UI elements, variable passing all quickly turn into spaghetti code. When building these kinds of sites, we were always left wondering Where should we store state?, Where should we store information about this or that?, Which file is that event handler located in?, etc.
In Angular, you get this for free. If you want to script a set of DOM elements on a page, you use a "Controller" or add that logic straight into the markup*. If you want to wrap up arbitary functionality or data, you throw that into a "Service". If you want to pass models around, well your out of luck (or in luck). Angular doesn't abstract data away, rather it uses js primitives like arrays and objects.
* Adding logic straight into the HTML is not only an Angular best practice, but pretty much a crux of the framework.
At Dollar Shave Club, each of our pages have varying levels of Angular sprinkled in, although every page has the same core "app" available to it, with respective controllers and services.
The more Angular approach would be to use what's called the "Router", which attempts to manage page state, URLs, etc.
In our server-side approach, every page lives at a URL, initially rendered by the server. Angular basically then hijacks the page and off you go. Think of it like is some third party did all of your jQuery selections for you, magically, then you just interact with their event as you wish.
Also in our approach, most clicks on links result in new pages being rendered by the server. This requires the "app" to be rebuilt, but we noticed the overhead to be very low. For instance, when you click on /about, we send you to a server-rendered "about" page, wherin our app is rebuilt from scratch.
Once your deep within certain pages of our site, for instance our checkout funnel, Angular becomes much more involved with managing state, altering the UI, etc. The Angular code for our checkout flow is indeed complex with more controllers and services added in, but nowhere near as complex/unmaintainable as it would be if written solely with jQuery/vanilla JS.