* If everyone generally views both language frontends as equal and shared responsibilities with valid technical rationales and only some specific/reasoned differences, then it's probably sustainable.
* If the team becomes polarized, or if one subteam wants to substantially reinvent their language ("Let's make it purely functional too! Bring on the monads!"), then yes... they'll feel hamstrung.
It might be interesting for them to consider comparisons with other systems that support multiple language frontends, e.g.
* GCC supports C and C++ (not to mention C++11, C++14, ad nauseum).
* HHVM support(ed) PHP and Hack
* JVM and CLR both support a range of language frontends.
My guess is that GCC is a more favorable analog (it feels normal+realistic to support C99 alongside C++11 and C++14). JVM/CLR seems like an unfavorable analog (they've supported many very different languages... but involve many large teams and diverse technical specs).
HHVM is probably the most pointed analog. It's just... mixed. On one hand, HHVM succeeded in supporting two similar languages for a long time (in spite of significant idiosyncrasies of PHP). On the other hand, HHVM eventually gave up on PHP and went pure-Hack. But (as an outsider) I'm not really sure the reason. It could be that they got boxed-in on a technical issue of language-interop, or it could be they got boxed-in organizationally (being a separate team maintaining a secondary implementation amid a continuous drip-drip of external changes - not a great position).
I interpret the original link above as basically an assertion (crude paraphrase): "The HHVM folks were broadly right about PHP and Hack and technology and all that; but their implementation hasn't succeeded on organizational grounds, and we-here can do those organizational things better."