There's a good video (warning, contains really a lot of swearing, but worth it) that will give you a good basis for arguing against this consultant... Solving Imaginary Scaling Issues (at Scale), by Laurie Voss at DinosaurJS conference.
The crux of the matter is that the consultant hasn't identified any actual, specific problem, so there's simply no way to know if the solution will fix any problem.
(Rehashing some territory from other answers here...) Scalability when used in this vague context means many things, horizontal scaling, vertical scaling, team scaling, etc. But they aren't the same, and when you actually need to fix something then you need to identify the real, underlying problem as specifically as possible.
If your general problem (scalability) was that your leg hurts, then one solution (new language) might be a cast, another solution (api change) might be antibiotics, etc., but you really have to know what the underlying cause is, e.g. broken bone, infection,..., (cpu usage, network times) to know which cure will actually do anything for you. And there are costs to using unnecessary cures, even in the best case they are simply expensive to implement, in the more common case they actually cause other problems when inappropriately used.
Your consultant should be providing you with real data about your system showing what the underlying problem is and why this will fix it. If you were currently experiencing the problem in the wild then I would want some metrics such as memory usage from prod, metrics from the ticketing system showing that devs are spending a long time struggling with language issues, whatever. Since this doesn't actually appear to be live now, I would still want some study with simulated load in non prod or specific areas of the code that will become difficult to work on or whatever. About the only time this random opinion nonsense is sort of OK is if the proposed solution is very low/no cost, like if the system doesn't even exist yet, but then I'd be more interested in opinions of the people who may actually maintain it one day, as opposed to a consultant who will be waving goodbye and leaving all the work with other people.
(I am on my fifth or sixth re-watch of this video, my management is notoriously buzzword happy and more influenced by outside opinions vs on the ground devs who could easily point out several problems which are low hanging fruit for fixing, so I have seen many of these ideas being proposed with actual seriousness.)