I think it would be nice to handle this, though there are a few issues to keep in mind:
(a) The CSS2.1 spec explicitly said that browsers must not justify when
pre-wrap is in effect:
If an element has a computed value for 'white-space' of 'pre' or 'pre-wrap', then neither the glyphs of that element's text content nor its white space may be altered for the purpose of justification.
So according to CSS2.1, the Firefox behavior here was correct. This is also reflected in web-platform-tests that Firefox and Safari currently PASS, while Chrome FAILS.
(b) The CSS Text 3 spec relaxed this requirement, leaving it up to the user agent to choose whether or not to justify in this case:
If an element’s white space is not collapsible, then the UA is not required to adjust its text for the purpose of justification and may instead treat the text as having no justification opportunities.
And the web-platform-test mentioned above has been annotated with MAY, to reflect that the behavior is no longer a requirement but an option.
So to change the behavior here would carry some risk of disrupting content that expects the CSS2.1-specified behavior. However, given that Chrome has been doing this for several years at this point, the compatibility risk is probably minimal. Still, sites (or tools) really shouldn't be relying on a behavior that is explicitly called out as optional in the spec, and seems to be implemented by only one of the major engines at this point. (Is there a corresponding webkit bug open about this?)
I'll also note that Chrome does not actually follow the CSS Text 3 requirements fully; the spec goes on to say:
If the UA chooses to adjust the text, then it must ensure that tab stops continue to line up as required by the white space processing rules.
but in my brief testing, it seems to totally lose track of tab stops in this case.