DRAFT
The point of an icon system is twofold:
If you have no icon system in place, it's easy to drop icons into a project in a variety of ways that leads to inconsistent visuals and no clear path for the developers working on the project. I've seen sites that use an icon font, inline SVG's, and inline <code><img></code>'s all on the same page as icons doing similar jobs. That's a confusing mess doing more harm than good.
With an icon system, you can reign in the confusion and create an icon system that is consistent and easy to manage. Even better, you can load the icons in a performance friendly way.
I'm a proponent of an SVG icon system (as <a href="https://css-tricks.com/icon-fonts-vs-svg/">opposed to say, icon fonts</a>). But what does that <em>mean</em> exactly... an SVG icon system? It doesn't really mean anything specific other than an icon system that happens to use SVG for the icons. There are dozens of ways to approach that. Let's take a look at different types of SVG icon systems and why you might choose any particular style.
You'll need to decide if you want to use an SVG-based icon system at all or not.
If your site has three icons it ever uses, I'm going to go out on a limb here and say you don't need a system. Perhaps some inline <svg> will do you just fine.
Another hitch in the giddy-up here is the fact that HTTP/2 has largely arrived. One significant change is that there isn't a penalty for linking up multiple resources (multiple HTTP Requests) like there used to. A major selling point of using systems like CSS sprites, icon fonts, or most SVG icon systems is reducing HTTP requests to one or none. If your site has 10 icons and implementing them with <code><img></code> tags will work for their style, <em>and you can use HTTP/2</em>, you probably don't need an icon system at all.
That's not to say you shouldn't have a system for generating those images, like, say, a Sketch file with multiple consistent artboards and design style that you output all together and optimize.
I'm sure there are limits to HTTP/2's powers here and those answers are still shaking out. If you need to load 200 icons on one page, having those all as separate requests seems like it might be still smart to somehow combine them into one request.
If you can't go HTTP/2 (or support an older browser set that doesn't support it) or have a reasonably large icon set, you'll probably still want to create an icon system. Assuming you're sold on doing that with SVG, let's explore more considerations.
(even icon fonts). Or perhaps, a single digital document (like Illustrator or Sketch) where each of the icons is it's own artboard. But the point of that is to be able to export them as individual SVGs.
Or the folder-full-of-SVG's can come from icons sets, converted from an icon font, from a icon site, drawn yourself, whatever.
You'll need to make some choices about artboard sizing. Cropped to edges or space around? https://css-tricks.com/svg-artboard-sizing/
You'll probably want to both keep originals as well as have an optimized set. Perhaps a build step that runs them through SVGO to remove cruft and whatnot, but also you'll want to make choices like... are we going to use strokes or only fills? All black or is color OK? etc.
There are many different types of "SVG icon systems" for example: