StarMade always used hardware rendering with OpenGL. You can check the same shaders in older versions ranging back to the very early days of the game. Minecraft also never used software rendering as far as I know. At the very start they used an older way to draw things in openGL (Display lists), which may not be the best for huge amounts of vertices, but to my knowledge they never used software rendering.
StarMade's rendering is done on the GPU, so the programming language used is pretty much irrelevant for performance (unless there is a bottleneck with too many calls, which would affect all languages).
Basically what you do is load things onto the graphics cards (e.g. chunks, textures etc), and then tell the graphics card to render it (specified by openGL settings and the shaders used). These are relatively simple calls like glBindTexture or glDraw*, which are sent directly to the driver. All the actual processing and rendering of graphics is done by the hardware, so at that point, the language used to make the calls doesn't matter, since they all speak directly to the same library (in StarMade's case OpenGL).
Software (CPU) rendering would be the slowest thing in pretty much any thinkable way, and you would probably not even get more than a fraction of a frame per second with it. Not only that, but you also would have to actually reimplement a core graphics library like openGL or directX into software which would be insane. So even if I wanted to, I couldn't even use software rendering.
In terms of synchronization of threads, it's also not really about the programming language. If synchronization is taking so much that it becomes a problem it doesn't matter what language you use, even if that other language would be technically faster. It's still a bottleneck that would slow down in the end. This is the case for a lot of other things in general. In projects of this scale, the speed of the language itself matters less and less, because the performance is determined by bottlenecks. In small benchmarks it's easy to see a difference in language performance. In millions of lines of code, it is no longer that easy.
What you probably experienced are things that bottlenecked the CPU in the past, causing your GPU to have less to do. A lot of these things have been removed, and more will come. A simple example would be switching from a chunk size of 16 to 32. Since this means 8 times less chunks it allowed processing the pure amount of chunks much more quickly, removing bottlenecks for huge amounts of chunks iterated through on the CPU. This made the game a lot less CPU bound and therefore you would experience a speed up, since generally gaming PCs focus more on GPU than on CPU for good reasons.
The game is still very CPU bound in a lot of regions, simply because of its nature: Fully editable vast amount of blocks with a dynamic block level physics. Compared to first person shooters that have mostly static geometry it is a completely different requirement. A lot of the things we did in the game was widely uncharted territory at the time. There haven't been any established 'this is how it's fastest' ways of doing things in a lot of cases.
As for settings, there has been another set of small improvements for the new version. The new LoD system will be part of the universe update which will likely be one of the biggest single boosts to performance.
All I can say is that I will continue to improve the performance. The game was written in a way that things can be switched to c++ if it makes sense, and things can be multithreaded if it makes sense. A lot of these things are planned for the beta, because once they are switched, changes will take a lot longer. And there are optimizations to be made that will have a much bigger benefit than a switch will ever have. So I rather do those first, and then switch in the end to squeeze out that little bit of extra performance.
My current goal is to develop features and at the same time keep bugfixing and improve the performance. Once the main features are complete, the focus will then completely shift onto performance and fixing, but also to make the game look better on higher end systems.
