I think tools for a programming language should be written in the said programming language if possible.
Rome developers will not use Rome to develop Rome, and the Rome users are less likely to contribute because they are more likely web developers and not familiar with Rust.
That's a nice ideal, but esbuild has managed to reduce build times 100x by building JS tooling in Go. Given how widely used JS it, the amount of time that would be saved by faster tools in this area is humungous.
The most significant performance-oriented effort in this space still leveraging JS that I know of is kataw[3], and while that's quite fast compared to babel, it's still within an order of magnitude from babel. Kataw itself is a CST-based implementation that was created to outperform seafox (a AST-based parser by the same developer), which itself is an iteration over several other perf-oriented parser projects.
Babel gained popularity due to the crazy amount of churn in grammar over the past few years, but more and more I think the dust is settling, and flexibility is no longer the name of the game, making an AST-based implementation less appealing. The Rome team must be feeling the heat if the data structure design choices are being informed by performance. I highly doubt someone will be able to compete in performance using a JS implementation in today's landscape.
[0] https://github.com/swc-project/swc
[1] https://github.com/sebbekarlsson/fjb
[2] https://bun.sh/