Recently, a big debate about the right frontend framework has been started in my company. This debate, however, is not new and certainly not restricted to my company. In fact, I know that many companies are standing in front of the same problem. Let's try to look at the different points of view and let's try to find an answer. Spoiler: I will not hide behind a "it depends".
Ideally, the choice of frontend framework does not matter. Independent if technology A is used in one project and technology B is used in another project, one can find the right choice for the specific team working on a specific project. However, once auxiliary factors such as maintenance, cross-application integration, decoupling, and others come into play the situation gets tricky. For instance, at my company we are currently creating a library with components to be used by web applications. Components which obviously come with some functionality, but will - most importantly - feature the official corporate design. This library should provide a common basis and make creating new projects quick and easy without having to dive into CD guidelines. Since the library features components with functionality we also need to decide for a supported frontend technology. As a result only projects with the exact same technology will profit from the library.
The simple example already illustrates that there is a need for such a library. Even if we start at a bare stylesheet we may want such a library to not redo work that was spend on autocomplete textboxes, color pickers, and others. Not many companies can afford creating and maintaining multiple of such libraries (due to supporting multiple frontend technologies). Another example would be an overarching application (frame app) that contains multiple "mini applications" (or high-level components) that may be able to communicate in a decoupled manner via the frame app. We cannot create these components with arbitrary frontend technologies - we need to limit the set of available technologies for coming up with such mini applications.
Now that we understood the need for a single technology (at least to some extend / under some conditions) we want to start the discussion between the most prominent ones - Angular and React. I drop alternatives such as Vue, Ember.js, or even interesting ones such as Elm for simplicity. In the end for most people only Angular and React will be up for debate. Just to be clear I need to emphasize that Angular is referring to Angular 2+, not Angular.js - which is also known as Angular 1.x. The latter is the source of many misconceptions such as Angular being more popular than React (e.g., having more available freelancers, more answers on StackOverflow, more search queries at Google).
Quite often the arguments that are exchanged in the Angular vs React debate boil down to the old framework vs library debate. While React was designed to be focused on a single thing (showing data in a view), Angular contains everything to be a fully fledged MVC/MVVM framework. It features a router, dependency injection, directives, and many more things to do that.
Where React shines is the ability to start with nothing and compose everything as we need it. Along that way we never have to leave JavaScript ideally. If we want to use TypeScript we even get "with XML" support out of the box. Since components are just pure JS abstractions we get great testability and potential platform agnosticity as well. This results in a possibility to use components and / or knowledge between the web and other platforms (e.g., mobile, PDFs, VR, ...).
Angular tries to convince developers by following a fixed structure. Less choices is less overhead is the trend here. Everything that may be needed is already given. On the other side that leaves many standard libraries and tools incompatible, while the gain is a (potentially) higher robustness in the inner framework. In comparison for React one may enter a spiral of death when library A assumes library B is at a certain version, while library C assumes a different one - but this is nothing new at React rather just a reflection of the Node.js ecosystem and immature libraries that are not properly designed.
What distinguishes React from Angular is the data-driven approach. In Angular developers have to learn a new DSL to annotate HTML templates. In React developers "react" to data changes with a render call that describes how the world looks like. Instead of going the usual imperative approach (I change x in data, I need to change y in view) we follow a functional one (I change x in data, I have the following view which contains the new version of y). The engine does the hard lifting of determining what can be reused and how changes need to be made. The data-driven approach is also the hardest part of the React learning curve. Philosophies are always more difficult to learn than names.
The interesting part of the Angular vs React debate is that this technology discussion is following Conway's law. It reflects the internal structure - a fully corporate conservative IT with legacy systems and strict processes vs an agile department focusing on developing prototypes at speed designed to be scaled. Who needs LTS for a small library that exists in multiple implementations and provides really stable and well-tested releases with no breaking API changes due to following semver?
Long story short: React is the right choice for everyone who wants to be agile, loves prototyping, and strives for a huge ecosystem and community. The alternative is certainly also suitable of building larger applications, but may be too restrictive and implicit to provide the basis for future endeavours of some kinds.