That's sometimes a good strategy, but breaks when you do too much at once. See boeing's recent fiasco where they did basically just that with parts and a fuselage that weren't really compatible. Metaphor extends: try to replace too much in part and something will break.
I would say the Boeing incident more so favors the counterpoint. Boeing tried to keep adding features to an airframe (code base) that could not support it.
The company I work for actually did this with our main product.
Gradually re-written from Java (JBOSS) to Python over about 10 years. Basically the Python side knew what URLs it could handle and proxied the rest over to Javaland. We ended up shutting down the last Java bits early last year.
Been doing that quite a few times back in PHP-land.
Partial rewrites based on Domain/Model/REST endpoint and just proxying to both webapps based on which was new already.
No breaking changes from the outside, either share the parts of the code that are still good (most of the business logic might be) or fork them (and then refactor and maybe you need to fix bugs twice) and after a while you can switch off the old part.
Works like a charm with added benefits of being in the same language to avoid wasting time. But the base idea works even if you use different languages.
It's also not for web apps, for example Apache Storm can do Bolts? (been a while) in several languages so you can also easily rewrite parts, if you can serialize your data in and out of it.
I would argue that if you already have a lot of in-house knowledge with Java then you might as well stick with it (and just not make whatever mistakes you made last time around) but Python seems like a reasonable alternative to me.
At the time there was a strong internal directive that it not only not be Java, but not anything that even looked a bit like Java if you squinted at it (e.g. dotnet) - plus we've always been an "anything but Windows" shop anyway
There's a lot of culture that comes with a language. 10 years ago, Java and C# were associated with enterprisey complexity and interchangeable programmers working under architecture astronauts, Python was used by the cool kids. Keeping to simplicity is hard when the available libraries and people you recruit were used to https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
At the time the re-write started, Django hadn't yet seen a public release, Rails barely existed (and had zero traction, and Ruby-the-runtime was horrible), dotnet was barely a thing, Clojure and Go didn't exist yet, dotnet barely existed. 2005 was a weird time.
Realistically the only options at the time were Python, PHP (4, not 5), or Perl.
I didn't come in until much later, but I don't really think there was a better option at the time.
1: https://en.wikipedia.org/wiki/Ship_of_Theseus