Not sure I'd agree with that. It's certainly always easier to start a new project, but doing it "right" in a way that you'll still be happy with years later is a much harder task, and one that few development teams achieve. In general, in real world development, this is one big reason why you try to be things as modular as possible - it's easier later when you have to rip parts out and replace them, and less likely that fixes in one place disturb some unrelated system. Unfortunately, strong compartmentalization tends to exist in tension with maximizing efficiency, so in performance-sensitive domains like games those practices are more likely to be sacrificed for other gains.
Definitely true in general, but it's been suggested that a significant portion of the codebase was overhauled with Odyssey. It may well have a fresh lease on life, once they achieve the big merge and retire the Horizons branch. The fact that they're able to iterate as fast as they have with the Odyssey update releases hints to me that the codebase and tooling are significantly more manageable now than previously.
I can bring in what I saw in 22+ years of experience working as software engineer in silicon valley; which is by any means no standard, but statistically if many companies prefer to start anew a project, instead of overhaul an existing one, there must be clear cost benefits.
Being modular is one of those mythical beasts that everyone talk about but you rarely end up seeing

Kinda like TDD; where everyone start with the best intention and down the road, the whole thing fall apart because you need to ship, you are late and can't worry too much about this or that. Write down technical debts and move on... And few years later you wonder who the heck wrote that code and how it even works.
To a point you can swap some parts, like libraries for example, but if you are writing logic that is not clearly divided by the interface and implementation (or if you want to go for the MVC design pattern, you are not making the controller and the view detached and mix up things across them), changes end up more and more problematic. when you have a small codebase you may keep things in check; but after years... I am not so sure, and Frontier is a big company and I imagine the codebase for Elite is quite large.
I would take the info given about codebase by Frontier devs with a grain of salt; especially because we have no visibility on the codebase, so whatever they say may mean something or anything at all. If I want to get a game that was made for a standard 2d camera, and add VR, that is done by changing some components in the camera area; but you need to change also part of the UI, and how interactions happens. If you add locomotion (space legs) to a static camera, the issue is not only related to change the camera parent point to the player, but you have to deal with other issues, like the player physics itself (is it touching the floor? does the animation for the IK work as expected? and so on), but you have also a whole different level of complexity related to how you manage the camera frustum, occlusion culling and a ton of other factors that you won't even consider when your camera is stuck in a cockpit floating above a static player mesh sitting on a chair.
Chances are that they added changes to the existing systems, replacing only what can be replaced; again without see their code we can only speculate. If their code is cleaner now, good for them; but I suspect that all that they did was to add on the back of the poor mule, an extra load and ship... This is what most companies do; and the huge amount of bugs in Odyssey and the fact that it took 7 updates to fix just the major issues, should be quite an amber light flickering as warning.