I'm going to make the completely unfounded assumption that Stored XSS was discovered first, as it's considered the more serious attack (which for now I'll state without justification) and then Reflected XSS was considered a variant type of attack, but different to Stored XSS because it required user interaction. But really the whole user interaction thing is a fairly weak argument these days, with the proliferation of ad-networks inserting arbitrary HTML in popular websites and 'watering hole' type attacks, a user just surfin' the net is far more likely than ever to hit upon a malicious iframe that exploits a reflected XSS attack. But granted, the user does have to be logged in to the web site so the window of opportunity for the attacker is smaller in a Reflected XSS attack.
Comparing to a Stored XSS attack, well the user is most likely already logged in to the web site so the attacker's window of opportunity is much larger, however that attacker could face a second issue, the victim still has to navigate to the page with the injected script, so the attack is location limited. It's interesting to note that Reflected XSS is not location limited, since the attacker will direct the victim to precisely the page with the vulnerability. But then it doesn't actually make sense to say Stored XSS is location limited if Reflected XSS isn't, because whatever vector of attack Reflected XSS can use, so can Stored XSS i.e. a malicious iframe can point to a web page with Stored XSS.
It would seem then that we should categorise XSS by the vectors of attack that can be used by an attacker to exploit a victim.
|XSS Type||the victim's response||the victim's request||the victim's DOM properties|
So it might not be clear what I mean by "the victim's response", what I mean is that the attacker does not control the victim's request, but is able to include data of their choosing in the response to the victim's request. This is the standard Stored XSS scenario where the data comes from the DB for instance. However Reflected XSS isn't possible because the attacker doesn't control the request and DOM-based isn't possible because either the vulnerable DOM property is set by the server, or set by the client with data from the server.
When the attacker manipulates "the victim's request", Stored, Reflected and DOM-based XSS is possible. Stored XSS because the attacker can direct the victim to the infected page. Reflected XSS because the attacker controls the parameters of the request. Finally, DOM-based XSS because the attacker can set DOM properties that aren't sent to the server e.g. fragment identifier if the attacker can specify the URL, window.name if the attacker makes a request from script.
In the case of "the victim's DOM property", what I mean is a DOM object property that is set client-side and not set by (or sent to) the server. In this case only DOM-based is possible, as the DOM property is not set by the server so Stored or Reflected XSS isn't possible. This is in fact a special case, or a subset, of the "the victim's request" scenario.
I've taken a fairly strict definition of DOM-based XSS here, as I think this is required to truly separate it out from Reflected XSS. My logic is that if the malicious data comes from, or goes via, the server, then the attack can be considered to come via the server in the same way as Stored or Reflected XSS respectively, but if the malicious data never actually gets sent to the server (e.g. it's in the fragment identifier, window.name, see domxsswiki for more examples) then that is quite plainly a different attack vector. Note that for DOM-based XSS a request still needs to be made to the server (most likely), so it shares that in common with the other attack vectors, but there is no malicious data sent as part of that request, unlike the other attack vectors.
There are other definitions of DOM-based XSS that are looser, that include any DOM property, even if coming via the server, and that's fine for most practical purposes. For the purpose of categorisation though I think being stricter helps understand how the different attack vectors for XSS fit together.
So there you have it, my opinion on the different categories of XSS, some people will agree and some will disagree. Generally speaking the security industry has settled on some loose categories of XSS, and that's fine, it's not clear we need strict category definitions, but it can be an informative exercise to consider them.
NB: I refuse to use Type-0, Type-1, or Type-2 names for the different types of XSS, they are meaningless names that only serve to confuse.