Are you sure you know what you're talking about? Are we talking about the same things here?
Are you saying that Star Citizen is using 64-bit doubles for their GRAPHICS pipeline? That's pretty much insane for the exact reason you mention--single (and half) precision float units are in the GPU.
Or are you saying "most games" use 32-bit floats for their PHYSICS calculations? Because that's also not a requirement and game dependent. Doubles are faster on many CPUs. There's a tradeoff for memory packing efficiency (using more cache and alignment issues), but floats are upgraded to doubles before being operated on on x86 and x64.
So for physics: Doubles are faster, and, they've been hardware accelerated for decades (even when CPU's were "32-bit").
But you mention both physics and graphics and seem to be conflating the two. The graphics and physics pipelines don't have to have related at all. Drawing with 64-bit natives is almost unheard of and would be incredibly slow on a GPU.
I haven't used the CryEngine but often times if you think you "need" a higher bit coordinate system (don't you mean 128-bit? ala long double? Doubles are already 64-bits and 80-bits internally.) you may be thinking of the problem in the wrong way.
There's no reason you can't (in most games) have a segregated coordinate system. For example, where each star is the center, the (0,0,0) point. And when you warp from one star system to another, the new star is the new (0,0,0) point.
Floats are great for huge distances, and tiny distances. They are horrific at BOTH at the same time... like say... adding a tiny fractional velocity vector per frame to an object millions or billions of units away. (There is a minimum amount you can add to a float without rounding down to the same original number, and the minimum change gets bigger the bigger the number is.)
IIRC, KSP does the same thing and coordinates are to the nearest "planet of influence"--which has the affect of removing Lagrangian points for orbits but otherwise works great without needing custom math types which are much much slower than native types, and it doesn't require ripping out all of the assumptions that an entire engine (Unity in the case of KSP) runs on.
When I created my own 2-D KSP, I ended up encountering all of these issues first-hand, and simply adding more precision didn't help nearly as much as segregating my coordinate system when we're talking about "astronomical" scales.
So if they're actually using non-native types, or having to change the engine, then they better have damn good reasons to do it. You don't change something that fundamental unless you're insanely brash, or, you've got a very-carefully-thought-out hard requirement that cannot be worked around.
If they really "need" space ships to have huge precision at any point in the universe regardless of proximity to a star, I would rather create "false/invisble stars" (almost like a quadtree/octree tree) where ever they are needed. Like when a huge fleet is moving around in free space, it would have a coordinate system following the capital ship. And if two groups of capital ships are attacking, you merge the coordinate systems.