It looks like the biggest culprit is poor or non existent lod's on the models. Strikes me as odd though as that's a pretty basic art requirement for a game like this. I don't see how this took them by suprise.
I guess the good news is that's it's easily fixable. It's not like ksp2 which looks like it has some pretty unsolvable core issues.
I read up until the part where it's using unity HDRP. I haven't found a way to make that perform remotely well on any hardware they should have just stuck with URP or legacy. The only thing HDRP even gives you on top is volumetric lighting and you'd be better off writing your own or using an asset with how poorly HDRP performs.
Game dev is not my wheelhouse but from what I gather in the article it is supposed to do some things better but the engine features (HDRP, DOTS, etc.) are still missing important features that led to a low of low-level re-implementations by Paradox...
However AFAIK game engines will not create LODs for you (and certainly won't prevent you from using overly detailed models) so that part is squarely on Paradox.
At the end of the day a game engine is like any framework, it can make things a lot faster and easier but will not prevent you from shooting yourself in the foot if you don't know what it is doing.
You're right, but you totally could make a game engine generate LOD levels for you. Especially for a game like this, where you could get away with a very crude LOD simplifier for tiny, distant objects.
In their case they can probably plug some open source library into their unity asset pipeline without much difficulty.
Honestly I'm just surprised they implemented so much complex stuff but didn't fix something so basic. Makes me wonder whether these blogs have correctly diagnosed the problem.
With Unity you can get the problems of poorly documented and maintained third party tooling, with the added benefit of having to make your own in house tools too!