For one thing, Firefox doesn't yet have an XSS filter, so reflected attacks can be executed on this browser.
Also, DOM-based XSS bypasses browser filters. This is not strictly categorised as "reflected XSS", however the end-result is the same.
Another thing to bear in mind is that browser XSS auditors do not constitute a security boundary. From Google:
No, XSS auditor bypasses don't constitute Chrome security
vulnerabilities (which is why this bug is flagged SecSeverity-None).
You can find our severity guidelines here:
To clarify a bit more, the XSS auditor is a defense-in-depth mechanism
to protect our users against some common XSS vulnerabilities in web
sites. We know for a fact it can't catch all possible XSS variants,
and those it does catch still need to be fixed on the affected site.
So, the auditor is really an additional safety-net for our users, but
not intended as a strong security mechanism.
There are bypasses found in such browser mechanisms all the time. IE example here. And, in opposition to another answer on here, filters do attempt to block POST requests too. However, you can never rely on these filters to block all XSS.
The upshot is that you should mitigate XSS on your web application through the use of output encoding, input filtering/validation (if possible) and hopefully a strong Content Security Policy.
Input filtering and validation can sometimes be tricky, however if you're taking input where the only valid input is say numbers and letters, if you want a secure application it is a good idea to restrict character sets to only those useful. Of course, this is not possible if you're running a Stack Overflow style site where you are allowing code snippets and such that make use of a large character set.
Remember that reflected XSS requires a user to follow, or be redirected to, a URL. Therefore it sometimes needs a bit of "social engineering" from an attacker to exploit. I usually classify reflected XSS as a medium risk vulnerability unless it can be automatically exploited from within the application (say an automatic redirect somewhere) or if the application itself is particularly sensitive.