개인적으로는 도구던 라이브러리던 자바스크립트로 작성이 되어 있다면 자바스크립트에 익숙한 개발자들이 그것들을 디버깅하고 필요하다면 기여를 할 수있습니다. 그런데 러스트로 재작성 되어버리면 오픈소스 기여는 러스트 개발자들만 할 수 있게 되어버리는거죠. 자바스크립트 개발자의 파이가 러스트이 비해 압도적으로 크기 때문에 오픈소스 생태계에서 툴이던 라이브러리던 자바스크립트로 작성되는 것이 더 유리할 수있다는 거죠.

자바스크립트 파이가 크다고 해서 컴파일러 / 트랜스파일러 코드베이스에 기여할 수 있는 개발자가 더 많을지는 의문입니다. 라이브러리 프레임워크와 기반 도구는 전혀 다른 영역이라고 생각합니다.

자바스크립트는 브라우저와 NodeJS 로 실행환경이 파편화되어 있고, 따라서 언어 사용자 수 사이의 단순 비교는 논거로서 한계가 있다고 생각합니다. 백엔드 스프링 개발자와 JDK 개발자, 리액트/앵귤러/뷰 개발자와 자바스크립트 도구 개발자는 관심사와 입장이 다르며 소비자와 생산자의 관계입니다

자바스크립트 도구의 성능과 사용성 개선 목표를 위해서라면 수단인 구현 언어를 바꾸는 것도 선택 가능한 선택지라고 개인적으로 생각합니다

저는 개발 툴의 소비자와 생산자를 명확하게 구분하기 어렵다고 생각합니다. 회사가 규모가 생기면서 툴체인에 대한 커스텀이나 추가 플러그인들을 본인들이 원하는 규칙에 맞게 커스텀하거나 구현하는 경우가 많은데, 이 경우 동일 언어를 사용하는 것 만으로도 큰 이점이 있다고 생각합니다.
툴의 사용자가 툴 자체의 개선사항이나 구현에 관심을 가져 자연스럽게 기여를 하게 되는 경우도 많구요.

툴체인 커스터마이징에 관심이 생기거나 그 업무를 수행하는 사람은 소비자의 역할을 넘어서 프로슈머 내지는 생산자의 역할을 수행하고 있다고 생각하고요. 플러그인의 경우에는 생산자와 소비자 사이의 플러그인 규약 안에서 움직인다고 봅니다. 해당 상황에서 같은 언어를 사용하는 것이 별도의 설정파일 형식이나 확장포인트를 제공하는 것보단 기술적으로나 의사소통 비용에서나 도움이 되는 것은 저도 동의합니다

다만 자바스크립트 도구의 성능 문제 내지는 NodeJS의 JIT 지연 문제가 소비자의 의사결정 범위에 있다고 생각하지는 않습니다. 그런 아키텍처와 동작 명세를 만든 주체는 툴 생산자와 런타임 개발자들이기 때문입니다