I think it would be very unlikely browsers would use a jit engine for xslt. They are removing it because they are afraid of the security footprint. A JIT engine would make that footprint much worse.
Not necessarily. The security issues are with the libxml implementation, a different one might be more secure even with JIT. That's part of what makes the whole situation so ridiculous.
Still, from a security perspective considering the low amount of sites that use it I think a better solution would be to implement it with a JS shim like PDF.js.
JS is already required to have a XML DOM parser, an universal XSLT engine in JS should be a low-effort web to continue supporting XSLT, as for performance the transform could probably be eval'ed and cached to JS snippets so that they in turn become JIT-compiled.
There are multiple CVEs in multiple Chrome-only non-standards that Chrome spits out by the hundreds in the past few years. They have no issues releasing those, supporting them, and fixing them.
Somehow they have an issue with supporting, fixing (and updating to latest version) this particular one. Possibly because it doesn't result in promotions.
Even without arguing over whether JIT engines are inherently risky or add much risk given the modern computing environment is full of them, from graphics to Javascript.