And it's particularly irrelevant if the front-end or back-end is weighted more heavily than the other in terms of product value, when you might hire distinct rather than "full stack" devs someday.
1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them
2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"
Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.
In practice, Point 1 isn't too realistic though:
Front-end and back-end almost always use different build/debugging tooling, different unit/integration testing frameworks, and even different paradigms. Unless your developers are good at constantly switching modes, it's hard.
"no real upside" is wrong, as you point out, but I would stand by "no guaranteed upside" :-)