I think the Mozilla link you provide has enough in it to answer your question (quotes taken out of order from the thread so I can tell a better story):
Firefox could do better using a (probably more expensive) algorithm such as the one described here (http://seclab.cs.sunysb.edu/seclab/pubs/ndss09.pdf). Interposing on script execution instead of HTTP traffic (as this paper does) makes for smaller strings to match which probably do not cause a big slowdown with this algorithm.
So this heuristic XSS Protection algorithm relies on a pile of string compares between the URL and the page content, and therefore will be frowned upon by people who want to keep the browser's CPU footprint down.
While we wait for browsers and websites to adopt CSP, a protection against reflected XSS attacks could be a useful addition to Mozilla. In fact, it could be implemented as a default CSP for websites which do not provide a CSP.
The implication here is that a generic heuristic running in the browser is strictly less effective than the devs of a given website providing a properly-implemented CSP saying what content should be allowed to run on their page.
There have been numerous discussions, the latest one in late 2016 and we
had come to the conclusion that it is currently not worth the effort for
Firefox to provide a built-in feature:
An XSS filter can not protect against stored (aka persistent) XSS or DOM
XSS, which has become more and more prevalent recently.
An XSS filter is prone to security holes if not maintained very
diligently and actively. It is hard to justify security engineering time
on a feature that provides limited value.
Lastly, there is an XSS filter in NoScript that people can use.
This one kinda speaks for itself that the XSS Filter is, at the end of the day, not that effective.