In my previous post, I discussed the steps to create a SVG for use in an AngularJS project, ending with a very simple interactive SVG in Angular. In that fiddle, the SVG was completely inlined. In the case where there is only one inline SVG, it really doesn't matter if all the CSS is internal or external unless you plan to switch style sheets at runtime.
However, once you have more than one SVG, it becomes more efficient to use one style sheet for all of them. Not only that, when you use inline SVG, the SVG XML is part of the HTML DOM, so CSS styles can collide if they have the same name. As in normal CSS, the internal CSS in the SVG that is loaded latest will win in the case of a conflict. Using an external style sheet consolidates all your styles in one place so it's obvious that you're trying to call different visual styles the same thing.
Given that the CSS styles can overwrite each other (not to mention that Angular 2 is dropping support for ng-include), you might want to use one of the other methods of adding SVG to HTML, an img or object tag, so that we can take advantage of the shadow DOM. Unfortunately, AngularJS also can't reach inside the shadow DOM. This is something I realized when I started building my own example where I was going to explore techniques for styling SVG inside the shadow DOM. But since the SVG can't be made interactive with AngularJS, it kind of spoils things. Sorry for the ugly example—I'd already pulled out the CSS before I realized the SVG wasn't going to be interactive.
It's going to be interesting seeing how this plays out with Angular 2's removal of ng-include. I wonder if people will have to go to reading in the SVG XML via HTTP and hand-compiling it to get interactivity, or if Angular 2 has taken out that capability as well.