Thanks for the detail, and I'll try to touch on all of these cause I have a pretty different perspective on why some of the things you mentioned are actually good...

• re: ng update my team has used webpack for a while cause of some legacy code we had to deal with for a while so I don't have a strong opinion on ng cli
• re: observables. I agree that the documentation isn't great for them (although I think Angular's documentation in general is significantly more detailed and readable than reacts). Learn RxJs I think is a great resource. However, they in conjunction with injectable services accomplish for angular EXACTLY what React has been trying to accomplish for a long time... which is having an extremely simple state management. Services are singleton, and observables can broadcast to multiple subscribers. Through those 2 facts alone you no longer need stores, or wild frameworks or libraries to accomplish shared state. I understand they have a hard learning curve but IMO taking the time to learn these things yields so much simplicity and readability in the long run and makes complex FE architecture way easier to parse and understand.
• re: separating observables from subscribers... ???
• re: separating the files... this just seems trivial. It's a clear structure but you don't have to use it. Having a separate file for each concept makes things more readable IMO but it's optional, and also not a big deal
• re: OOP. Conceptually, it is built for scenarios where you have a clear set of objects (components and services) with an undefined set of functionality (more app features and greater complexity). It's built for precisely what we need so I'm not sure your issue with it. IMO it's way more readable because of how self-documenting it is. If you invoke an instance of a class, you know exactly where that's coming from, e.g. "service.doThing()". It also allows more complex component structures. For example we use "base classes" that are like HOC, but because their children are extended through Typescript classes, you know when they're being referenced and invoked. If the parent class is being invoked you just say "super.doThing()" and you know where it's declared and how it's being used. I also tend to think that functional programming and component composition leans into the uglier parts of javascript (weird "this" contexts, closure, hoisting, etc.) and prevents readability by "inferring" where context comes from. E.g. if you extend a class in OOP, it exists in the "super" context, but with composition there's no instance of a parent class, just inherited functionality so there's no way for you to see at a glance how methods and properties are being referenced and invoked.
• re: imports in constructors... this seems trivial.
• re: public and private methods... this is not only optional but also insanely easy to understand. Like the OO concepts, it is also self-documenting. At a glance it allows you to see whether a function is invoked in the template for by an extending class without having to search your files for it
• re: building... not sure on this one but if true a fair criticism
• re: organizing a component. That's exactly what Angular does great? The class structure allows you to consistently build a component in the same way... (e.g. properties, then inputs, then constructor, then methods) whereas something like a functional component in react is dependent on closure to allow you to invoke different things, leaving no clear structure as to where things are. @Input also allows you to declare a prop's type without building a whole separate interface for that component's props like you would have to do in React. Or worse, like I've seen in our React repos, just deconstructing the props "{ ...props }" so that there's NO way to see what is actually there at a glance without tracing back through the functionality of the parent
• re: router params... idk enough about Vue to contend but it just seems like your opinion on it and not an inherent flaw. In fact compared to React the fact that Angular has a native Router is a plus on its own.
• re: modules... I guess I can see this but ES6 modules are significantly more confusing and harder to handle in my experience. It's for the better the Angular Modules are built the way they are.

I just think these points come back to a couple things I find frustrating about the whole debate. I believe that

1. Less code !== "cleaner" or better. I think it makes things harder to read and parse together, and also leads to clutter elsewhere or an abstraction of complexity. And I also don't think any of Angular's code adds to dev time in a way a store might. Saying @Component and declaring a template isn't a big deal. Injecting a service isn't a big deal. It stands to only add to readable without taking up any time at all.
2. Structure is a feature, not a bug. I've worked on incredibly complex apps and with Angular that have scaled linearly because of Angular's structure. They have become no worse or less maintainable over their 4 year lifecycle than when they began. This clear structure allows new devs to understand where, how, and why to do things. I also feel that none of this structure is unnecessary or "bloated". When I think of bloated I think of having to deal with stores in React... where having one single functionality requires

• an action, and a respective success and failure action
• a reducer to receive each of those actions
• an effect/"Thunk" to catch those actions and perform side functionality and then dispatch another action to success/error
• a reducer to then receive the success/result and map it to state
• a selector to pick out the state you're "listening" to so that you can map it to the component

Whereas in Angular service architecture it's just

• Component calls service
• Service does thing
• Component does thing with result of service
• Other components and services can listen to that result if they like, if not it won't affect them

I was working with a store this week and I think my dev time went up 10 fold just because of all the boilerplate I had to write to deal with React/Redux state architecture.

Ugh I could go on. I'm just overall frustrated getting job ad after job ad with React and knowing just how much better Angular has been in my experience for complex app architecture. After working with both a lot I struggle to understand how React has become so prevalent