That said I did come into companies as CTO where I should have started a rewrite. The code plainly was not able to scale the way it was written. We had lots of trouble with scaling and I struggled balacing feature pressure and technical rewrites of parts of the code base in order to scale. Getting in and start with rewriting the code base for 6 months so it would scale would have made things much easier for all developers.
As a CTO coach this is also what I tell my coachees now :-)
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
A CTO is responsible for ensuring that the company is able to deliver what’s needed, and if the current stack has issues, including ok-now-but-won’t-scale issues, then they should switch it out for one that positions the company for success.
OTOH, it could be motivated by a range of unjustifiable things: personal familiarity, resume building, blind trend following, asserting of authority, etc.
In most cases, the engineering staff can tell whether the motivation is good or not.