The biggest problem is the unstated motivations at play around ego and ambition. People want to be influential. They want to use the latest technology. They want to be the ones to make important decisions around architecture and style. They have their personalities deeply bound up in the technologies they use, so technical merits and technical problems quickly translate into personal emotions around things - insecurity, defensiveness, secretive behavior, - all of which is unstated and manifests in passive ways.
Our problem is sort of the opposite though. We chose Python as the "backbone" language - the glue that holds other things together. However the team is small and inexperienced and mostly only know Python. So they persist in using Python for every other task as well. Unless I make it a hard requirement not to, they will pick it up and use it for performance sensitive things, things that have significant structural complexity where Python's type system weaknesses really hamper it.
So we have problems where we have a design meeting and we say "We need an X. X should do Y and Z". We all agree. Then I come back a few days later and team member A announces he implemented X "in his spare time". So we now have an X. Written in Python, which is not the optimal language I would have chosen. Only team member A understands it, so everybody else is a step behind and didn't have any input. Team member A made all architectural decisions for it. X is well written, seems to work and now that we have it, it is hard to argue time is well invested in writing it in a more optimal language.
What do I do? "Have a chat" with team member A (ie: discipline them?)? Praise them for taking on an important task? Do we rewrite this component? If I do all these things am I being heavy handed and causing untold harm to the team morale? But what are the consequences if I don't intervene - can we actually end up with good cohesive design if every team member is just steering the whole team in whatever random direction they happen to want?
It's harder to make people appreciate enforced type discipline until they've written a large enough system in type-annotation-free Python that it starts really hurting. I attained that painful enlightenment along with the rest of my all-Python team 12 years ago at a now-defunct startup. I still like Python for small programs, especially many kinds of exploratory/prototype work, but nowadays I'm using Scala for most things that go to production.
Have you had bugs show up due to type mistakes? Changes that take longer than they should, since the IDE can't automatically identify the type-consequences of a change? If so, those concrete examples might be motivating enough to gradually introduce type annotations in your existing Python code, which might be a stepping stone to using a stricter-typed language.
We're at a very greenfield stage of development, so part of the problem is that we are yet to feel much technical debt pain from everything that is going on. And a lot of it is invisible. Eg: in the example above, I needed to put aside time to review the code that was created for component X. Because it was written in Python, this review was quite a lot harder than if it was well written code in a more structured language. Most arguments to most functions have no obvious data type documented or constraints around nullability set etc., so figuring out what everything is involves a tremendous amount of reading code and navigating up and down the code hierarchy. Multiply this by every team member who has to understand and ultimately maintain this code and you have a tremendous cost. So in a real way it is definitely costing us already, but its very hard to measure. But as you say, my real worry is about the longer term. It's easy to figure out what a data type is when a function and its caller are right next to each other in the same file. But as things grow and they get split apart, maybe even into different modules or projects altogether it gets massively harder to do. We could go all in on type annotations but I see it as a bandaid compared to the team actually investing in using a core structured language where the typing is a first class citizen.
Do E2E testing, test the API. If you later find out that the implementation is lacking, yoi can swap it out with confidence, if you have 100% coverage of your API spec.
Also, as a sort of management recommendation, you need to set the bounds and find the people that can work with you, not the other way around. (Yes, of course, you work with what you have, but this doesn't mean anything implemented in spare time must become the next cornerstone of the company/product.)
And you must spend a lot of time growing your teammates. Because with a great team a rewrite/refactor will lead to better results, with the same quality team, even in a "better" language you will only get similar low quality results.