I would approach it from these perspectives:
1. What kind of testing are you doing ?
Is it at the unit, integrated or end-to-end level? Is it white, black or grey box?. If it is at the unit or integrated level and you want to call existing routines in application code, this obviously lends itself to advantages from using the same language. If it is at the end-to-end level through a browser then it may make sense to use a different language. For example, currently Cypress.io is used a lot for browser testing so that means Javascipt, regardless of the backend language / frameworks.
2. What are you using for the backend language?
3. What are the team dynamics ?
Are QA engineers embedded on application development teams and able to pair with fellow language developers, or are they segregated into a separate team where their pair is usually another QA person. The former makes a stronger case for sharing the same language for code.
4. What capability do you need from the testing tool?
For example for browser testing, cypress.io typically gives a much better experience than using selenium so the features and capability of the platform may outweigh the advantages of sharing a language.
5. How are you organized?
Are QA's paid as much as devs? Are QA's involved in all planning activities? Do QA's review application code for bugs? The more involved QA's are in application development, the more reward comes from sharing a language. Also, if QA's are second class citizens they will typically use the programming language learning opportunity to become a developer and get paid accordingly. Or they leave to get the same benefits elsewhere. This can led to a low quality automation codebase continually worked on by newbies.
6. Are different programming goals recognized ?
Application code and automation code share some quality characteristics but their priority can be quite different. Application code can have a focus of being performant and both memory and time efficient and may use extensive optimization to do so. Automation code on the other hand tends to focus more on readability (by treating the tests as the specifications) and how well application code is being exercised. It is important that these differences are recognized or the wrong foci will be used when programmers from one discipline pair with those from another
7. What structures are in place for pairing ?
Pairing can be a new or difficult practice and when performed by specialists from different areas such as dev and test, there are many organizational, culture and possibly geographic barriers to it succeeding organically. Also programmers may be introverted and not want to share by default. Leaders, coaches and guides are essential to make sure that collaboration happens in practice and not just 'because they use the same language'.