닷넷의 언어중립성이 실질적으로 어떤 이점이 있나요?

원래 주언어가 자바인데 요즘에는 C#을 공부하고 있습니다. 유사점이 많아 서로간에 새로 배우기가 쉽다고 하길래 말이죠(솔깃).
음... 그런데 닷넷 플랫폼의 특성을 읽다가 IL을 통한 언어중립성이라는 부분에서 고개를 갸웃하고 말았습니다. 언뜻보면 굉장히
좋아보이기는 하는데... 실질적으로는 무슨 이점이 있나하는 생각이 들더군요. 여러 언어를 지원한다고는 하지만 결국 하나의
메타언어로 표현되는 것이고 곰곰히 생각해보면 껍데기만 다를 뿐 속은 닷넷이잖습니까? 물론 기존의 개발자들을 가능한 거부감없이
새로운 플랫폼으로 유도한다는 상업적으로 매우 중요한 이점이 있겠지요. 제가 이해할 수 없는 건 '개발상의 이점'입니다.

아무리 겉보기 뿐이지만 개개인이 자신이 자신있는 언어로 진행하는 닷넷 프로젝트를 생각해보았습니다..... 잘 상상이 안가더군요.
통합에 아무리 문제가 없다고해도 하나의 프로젝트에 각자가 자신의 언어를 사용한다니... 의사소통 문제라던가 서로간에 소스를
공유할 때의 효율성에 문제가 있지않습니까? 개인적으로 이것저것 사용하기에는 재밌고 편할지 모르겠지만, 실무에서 언어중립성이
어떤 도움이 되는건지 궁금합니다.

그리고 부가적으로, 닷넷의 VM은 왜 그렇게 비대한가요? 자바는 플랫폼 독립성을 지키기위해 어쩌구 저쩌구... 할테지만 닷넷은
'윈도우'만 타겟으로 생각하면 될테니까 훨씬 더 최적화하고 뺄 수 있는 부분이 많을거라는 생각이 들던데요. (모노 프로젝트가 있지만
그건 그냥 오픈소스고, MS가 진심으로 윈도우 이외의 운영체제에 신경을 쓴다는 것은 도저히 믿을 수가 없군요)
당연한 걸지도 모르겠지만 윈도우 개발에 있어서 닷넷이 편리한 환경을 갖춘만큼 타 운영체제에 적용하기란 힘들거라는 생각이 들었습니다.

일단 '상황에 따라 필요한 도구를...'이라는 말은 좋지만, 실질적인 이점은 잘 모르겠습니다.
JVM을 사용하는 가장 큰 이유는 플랫폼 독립성인데 그게 목적이 아닌이상 왜 비대한 VM을 사용하는지 모르겠습니다. IL을 포기하고
GC나 C# 언어상의 간결함은 유지한 '진화된 MFC'를 만드는게 더 좋았을 것 같은데요. 그러면 닷넷이 아니라 Visual C#이 되겠지만
말이죠. 처음에는 그냥 그러려니 했는데... 공부하려다보니 '왜???'라는 생각이 뭉게뭉게 드는군요. 차근차근 가르쳐주시면 감사하겠습니다.