I think the real mistake in that scenario is not minifying the code until "in production". You should minify your code from the day one.
Although I agree that the "not safe for minifying" mechanism shouldn't have been included in AngularJS.
On the other (other) hand, it's pretty abhorrent that minifying is something that developers need to actually place any thought into..
How are you debugging minified code?
For #5 the real deal is the provider and everything else is syntactic sugar on top of it. Once you have a very large application you start to appreciate the distinction. The naming of concepts is awful though; could have been much more clearer.
I'm sorry to say it's pretty "retarded" to add in framework-specific minifiers to the build process. I don't want to tweak 10 different minifiers if I'm using 10 different libraries in my application.
#3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be in production.
#5: The service/factory distinction adds a conceptual complexity that is completely unnecessary, as demonstrated in this blog post.
#7: Having too many watchers will slow your app down to a crawl on a desktop machine, and be even worse on a phone. This happens more easily than you'd think and it's fundamentally caused by Angulars reliance on its digest loop. This loop is the essence of how Angular works, and it means that there are tons of applications that cannot ever run efficiently if they're built on Angular.
8#: Because of the way their $scope system works, it is actually literally impossible to tell what the the meaning of ng-model="foo" is by reading the program. It may in fact depend on the order in which the user interacts with elements of the web page. Consider this example: http://jsfiddle.net/7kkxLkxh/ What foo binds to is dependent on which input you type into first. Yes, there are ways to avoid this, but it should have been avoided by either disallowing this construct, or requiring foo to be declared before it is used. (If you miss a var in JS, you get a global - that turned out to be bad language design. Removing the var keyword and effectively deciding on variable scope at runtime is certainly a much worse language design.)
After working on a large Angular project, it is clear to me that there are a lot of ideas in there that are frankly not good. It's sad that there seems to be very little discussion anywhere about the downsides of the various frameworks that are out there.