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.