Honestly, if you have an autonomous work culture where teams do vastly different things to accomplish the goals of their delivery, why not? And if the project is smaller, has a rock solid technical path, then perhaps not the best choice.
Your example is a bit extreme but it is essentially right. Nobody should have to learn old code base components if they are just going to make a new thing, and perhaps utilize some api's to the old thing. Doesn't even have to be the same language, framework, whatever.
I suppose it's up to the culture and willingness of the people that work there to learn and apply themselves to maintaining such a solution. Traditionally I've found (in the ones I've worked for, at least) that companies tend to stubbornly stick to a particular stack. Introducing new technology is seen as an overhead (which it is!) since it will impair onboarding time for existing developers.
The example was more of an aside - an additional benefit to suggest that even if all the tech you use is the same, this could be another reason to go this route. I've seen a few corporate systems that got re-written because it was written in VB6 or some other legacy language/framework. Since it was a monolithic app, it has to be done all at once. This always takes far longer than scheduled with many mistakes, much stress, and panic from all stakeholders. My point is, at the very least, this allows you to rewrite a system, one service at a time - phasing it out slowly and steadily, rather than replacing everything at once.
Honestly, if you have an autonomous work culture where teams do vastly different things to accomplish the goals of their delivery, why not? And if the project is smaller, has a rock solid technical path, then perhaps not the best choice.
Your example is a bit extreme but it is essentially right. Nobody should have to learn old code base components if they are just going to make a new thing, and perhaps utilize some api's to the old thing. Doesn't even have to be the same language, framework, whatever.
I suppose it's up to the culture and willingness of the people that work there to learn and apply themselves to maintaining such a solution. Traditionally I've found (in the ones I've worked for, at least) that companies tend to stubbornly stick to a particular stack. Introducing new technology is seen as an overhead (which it is!) since it will impair onboarding time for existing developers.
The example was more of an aside - an additional benefit to suggest that even if all the tech you use is the same, this could be another reason to go this route. I've seen a few corporate systems that got re-written because it was written in VB6 or some other legacy language/framework. Since it was a monolithic app, it has to be done all at once. This always takes far longer than scheduled with many mistakes, much stress, and panic from all stakeholders. My point is, at the very least, this allows you to rewrite a system, one service at a time - phasing it out slowly and steadily, rather than replacing everything at once.
Sure, it makes sense. Strang(edit: l)er vines pattern.
Strangler? Yeah