Generally, from an engine design point of view, physics and rendering are unrelated and only have contact with each other in so far as the renderer must receive data from the physics part to know where to render what.
I do not know how they are related in Godot and to what extent they are tightly coupled, i would assume (and someone please correct me if that's wrong) that physics and rendering run in different threads and synchronize somehow, simply because the renderer can (and does) run with different frame rates than the physics ticks, the former being variable, the latter fixed to avoid numerical instability.
For your game made with an engine, you simply have to rely on the engine doing it in a reasonable way, or you'd have to brew your own physics and integrate it as an extension into your game. If you need to solve differential equations you'll certainly have to go that way, if I just check for collisions I'd want to rely on the engine's capabilities and only start to question when things aren't looking "right", in which case I'd per default search the error on my side before digging deeper.
I can't really imagine how to reasonably do 3d in 2d. Well, maybe calculating orbits in the simple 2-body problem are ellipses on planes, so that would work. But passing the data in for rendering needs 3d things again. Anything else where life's ups and down play a role you need the third dimension. Don't worry so much about performance prematurely, only when it starts to show that your scene won't render fast enough, then you'd have to think about solutions.