It depends.
I’m working on a game with Unity and the software design has been done in a way that keeps most the game itself as data, and uses the Unity stuff mainly as something to display multiple views on the state of the data (a 3D view of the game space, multiple UI elements diving into slices of the data an so on) - basically a Model-View-Controller Architecture, so moving from Unity to something else doesn’t require a rewrite (in fact such structure makes it possible, for example, to with some ease change the game’s visuals from 3D to 2D), though it would still be quite a lot of work.
However my game is survival-management in space (within one or more generated star-systems, so it was simplified down to a 2D plane) which doesn’t relly on Unity things like terrain, navigation meshes or even colliders to constrain the movement of objects in the game, so calculating “what happens next” (say, the movement of planets or the guidance of ships going from planet to planet) gets decided using Maths at the data level without going through the Unity layer, and Unity is mainly the means to get user input comes and the layer that gets updated with the state of the data at the end of each cycle (i.e. game objects get moved around) which it the uses for rendering.
Other games which are not reliant on Unity to do the heavy lifting for objects interactiong with other objects on a 3D space, such as 2D platformers, can probably use a similar architecture, but for example something like Valheim or Planet Crafter (were the player controls a humanoid avatar on a 3D world which is mainly terrain) is probably much harder to move out from Unity,
Not to mention I’m sure they use third party tools to help with things. Bigger games like Genshin Impact for example, are on an older version of Unity where they heavily modified the engine to suit their needs. That would take a tremendous amount of work to move, and they’d have to redesign their entire graphics pipeline. Which also Godot has gotten better, but is still far behind the others in terms of high end graphics. That’s why it’s usually seen as the go to for indies, and not so much high end games. Also they don’t plan on making anything like DOTS, but I’m not sure how relevant that actually is.
Third-party tools might or not be a problem depending on whether those tools also support other frameworks or there being equivalent tools for other frameworks.
Again, it depends how tightly coupled the game is to the framework (directly or via 3rd party tools), but yeah, the more work you’ve sunk into the Unity-specific side of things and the more tightly coupled your game is to it (i.e. doing everything via Unity rather than, as I did, make the game run as a data model which then dictates how the visual layer - which is where Unity mainly is - is updated) the harder it will be to move.
Mind you, the Unity guys really pushed for devs to go via it for everything (it’s software design and architecture aren’t exactly great) in a sort of spaghetti design, so I expect a lot of indie devs using Unity who don’t have quiet as much experience and/or it’s not really broad, will get burned due to falling into that specific trap.
The Godot tools are significantly behind Unity. Unity has a much bigger community and a built in store for their addons. Godot has neither, and has been around for less time. Godot doesn’t even have a built in terrain tool for example, and the most advanced plug-in for it is still pretty basic.
