To the terrain questions 1 and 3: Godot does view frustum culling; so yes, if you divide the terrain into indvidual meshes, Godot should cull the ones that aren't visible in the view frustum. But frustum culling won't usually discard more than say, roughly 50% of the terrain, depending on your position and view angle. Note that general occlusion culling (not rendering stuff that's occluded by the terrain or other objects) is much harder to achieve efficiently and isn't done by Godot, so you'll have to do your own implementation if you want it; one common method is to section the world into parts that don't see each other and connect these sections with portals; this means you can discard large parts of the world. There are algorithms that do the sectioning and portal creation automatically; but if you want a ready-to-use solution, you'll most likely have to pay money for it.
I know of two clever ways to render large open-world terrains; one (possibly the more modern one) is using quadtrees to achieve chunking and lower LODs for far-away terrain (this is what Zylann's plugin uses), the other is using a pyramid of clipmaps.
But before you start worrying about optimization, you should think about your actual requirements. For example, an open world that spans 64 km squared with a resolution of 0.5 m will require that you stream in terrain tiles from the hard disk and have you think about how to solve this efficiently, while a 512x512 m world with a 1-meter-resolution probably won't need much optimization at all on a desktop system - you can simply have Godot render the terrain mesh in one go, even on integrated GPUs. Don't worry prematurely over otpimization. Do experiments, use Godot's profiler to see how fast they are running and where the bottlenecks are, and then start finding solutions to the things that need to be faster.
For example, I recently noticed I'm better off having Godot construct a fully new texture for something every frame instead of updating the tiny parts of the texture that actually change, because figuring out which parts change using GDScript takes more time than simply constructing the full texture from scratch. But this is only a valid observation in this special case; other times, partial updates, or even a C++ solution, may be the way to go. It's the same with terrain optimization - the optimizations that are required vary greatly with the requirements you have.