That's generally decided by the experience of the existing team members.

... whom an inexperienced hiring department entirely trust when they assure that the technologies they are already familiar with are the best fit for the company, let's hire only people who think the same?

I'm not sure if you're being obtuse. But rewriting your stack in a language no one on the team knows because someone on HN said it's a better fit for your usecase is something no good engineers/managers would think is a good idea. If a potential hire thought that was a reasonable thing to do, that would be a major red flag - a sign this person lacks experience, and any kind of business understanding.

It depends, if a potential hire suggests using Python instead of R or Java to process data, that's a reasonable proposal.

Caught me as an odd choice to scale an IoT backend.

at some point you end up with path dependence -- you're in the situation you're in, and it would be big-bang rewrite or incremental migration to port all the code to a new stack, not to mention the costs of retraining existing staff to be able to effectively develop in and support the new stack, or replacing the staff with different staff who know the new stack but don't understand the existing business and code. so maybe the previous decision to pick tech stack A over tech stack B when starting the product was pretty sound given the circumstances, or maybe it wasn't, but it doesn't matter that much from the perspective of deciding what to do next.

Oh yeah, I know all too well about path dependence. That's how we end up with a Rails monolith that's written in a very standard/structured way so that many devs can contribute, add type annotations for safely/docs, etc. Using no types is like having no tests and thinking about adding them later. Usually better to have it in place as you go.