I think the problem you're worried about is what is going to happen if you don't use delta, or game logic or nodes that are fed by delta time.
The game loop measures and works to keep timing synchronized. Delta is a value it reports as it works to do this from frame to frame.
Another benefit worth mentioning is that if you decide to change the frame rate of your game, and you're using delta, you don't have to manually adjust any of your code or values.
I should've pointed out too that you may want to use fixed_process() rather than process() for mechanics that need to be more accurately handled over time.
The process() function is more for rendering, and the delta will be variable. I haven't tested it in Godot, but I think it still will give a value that tracks to the elapsed time. It tries to hit your frame rate, but it if it doesn't it will adjust the delta it sends to reflect the difference since the last time it updated. Meaning if you lost a whole frame, the next update you will have a delta that is twice as large, which should keep the values accurate over time.
If you want to see the difference I would recommend just doing a print(delta) in each function, and watch the output console.
A game loop is generally split into two parts, the physics and the rendering. For the physics part, which is fixed_process(delta) in Godot, it will generally aim to keep time as best it can, and all timesteps are a fixed size. This is important, because of lost precision in rounding floating point numbers. If you have .01444 then .01788 next frame, you might lose some small amount of accuracy in the multiplications, even if it averages out to .01666 over 1 second.
When using a fixed time step, if the game loop falls behind, it will begin doing multiple updates per frame to catch up, and begin to defer the rendering. As long as it can do this, it will keep the simulation accurate. The game may hiccup visually, but it will do all the calculations in the meanwhile. So your amounts like distance traveled and fuel consumed will still be calculated 60 times a second. The loop will measure and check the time to make sure it is staying faithful to 60 updates a second, even if they end up being awkwardly spaced out because of performance problems.
If your game can never catch up, than there is only one solution for that, you have to reduce something or find some optimization solution, because the machine you're using cannot handle what you're asking it to do.
For the occasional spike in performance, things should be fine, this is what delta time is designed to handle. However, in the extreme cases, when things are so bad and physics frames have to be dropped to keep the game from locking up (spiral of death), then you have to consider the metrics of how much work is being done and how much the hardware can handle.