There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store.
As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.
Maintaining two API binding layers is perfectly feasible with the attention and resources Godot is attracting.
Unlike with Unity interested parties can jump in and lend a hand. You'll have two groups(perhaps overlapping) maintaining the compiled and script bindings.
Maybe GDScript could just get the concept of a struct and the differences minimized over time too.
From what I'm reading here and elsewhere, we'd need to do some fundamental mucking into the c++ layer as well, given some data oriented hostile practices.
But yes, I think it'd be best long term to treat GDScript ad C# the way Unity treated GameObjects and DOTS. DOTS's goal wasn't to kill gameobjects, and in fact a lot of work went into bridging between the two with hybrid packages. I guess we'll see if that kind of initiative gets some momentum (and I'd love to help out if so!)
As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.