I think that's orthogonal. You can fall behind just as easily by not addressing technical debt. Consider how easily it is, particularly in the JS world, to accrue multiple different bits of UI written in different frameworks du jour.
Rewriting stuff is very seldom in the business' interest, but stuff gets out of date at a rate controlled by the ecosystem, not the company.
Generally speaking, the worst kind of legacy code is the kind that cannot be easily rewritten. That's why I particularly called out custom frameworks and custom languages. Replacing custom service implementations, in comparison, doesn't even count as "replacing stuff" since it's so trivial.
It's not in the company's best interest, generally, to write business-critical things in ways that are hard to replace and/or pivot on. This means that a company needs to account for the whims of "the ecosystem" in both its business plan and in its technical strategy. If it's a huge concern, the profit margins need to stay high enough and customer expectations need to stay flexible enough to mitigate the concern. Also, if "the ecosystem" is a huge concern, technical strategies also need to help mitigate. For example, if you're running the same JS code both client and server side and you're worried about changes in the client-side ecosystem, you might want to think about implementing the backend in something more boring and stable just to mitigate ecosystem risk.
The code that you can't afford to rewrite is the code that is hairy with details. The details are some mix of essential and incidental complexity. The ratio is dependent on the degree of fit between your business logic and the framework, the primitives it's built out of, whether it's third-party, custom framework, custom language, whatever. And of course any custom component has its own complexity; it should be additive, but it may still be large. A good fit - an excellent fit - means your business logic is clear, concise, and is operating over abstractions that map directly to the business concepts. A poor fit is speaking haltingly in unidiomatic language, too verbose, aggregating globs of ugly code, losing track of the forest for the trees, etc. But it'll be easier to find average devs who are familiar with the particular style of thicket that ends up coming out. We even have names for the scar tissues that grow around each glob, helping them interface - we call them design patterns.
There's no hard and fast rules, it seems to me. Use a small fraction of lots of different third party bits and pieces and you get a recipe for pain. I'm fairly certain there's no more productive way for engineers to code than to raise the level of their language into their business domain - http://www.paulgraham.com/progbot.html - but this is the custom framework / language approach. I'm also fairly sure that it's hard to scale an organization around this approach because of the incentive problem when hiring developers. I think it only really works for startups that are composed of a bunch of hackers with decent equity stakes. It doesn't work out for employees, unless the company ends up moving the needle industry wide, like Java or Rust or React, and that's really rare, too rare to bet on.
Rewriting stuff is very seldom in the business' interest, but stuff gets out of date at a rate controlled by the ecosystem, not the company.