I'm going to guess it went something like this:

They kept on adding visual features that work independently, making all their own API calls, one after another, got it looking good, and moved on. That's as opposed to creating a cohesive rendering pipeline that deduplicates effort and accomplishes the same.

On top of that, and most importantly, I doubt they allotted time to refactor and optimize, or... they allotted it after release.

If you thrash Unity's APIs hard enough, which in turn thrashes the underlying vulkan/DX level APIs, clever drivers aren't quite enough to keep the GPU loaded with useful work.

There's probably a long tail of other stuff they need to profile and tweak to get a better balance of performance to visual quality, like changing the precision of shader calculations, tuning level of detail, and so on.

Well, they both use the same engine. That might be a hint. Yes, to be clear, I'm talking about Unity.

That’s one of those convenient non-exploratory answers I’m hoping to dig past. It might be related, but we don’t really know based on this alone.

Virtually every Unity game ever that does a non-trivial level of background simulation has considerable jank. There’s just a point where you hav wot say - look - Unity games consistently have performance issues at some point it’s legit to just call it a poorly performing platform.

Cities Skylines 1 performed remarkably well on midrange computers, particularly for just how good the simulation is and how busy the viewport can get.

The same cities skyline where traffic hasn't worked properly since day 1? It may not be as bad as some, but C:S has plenty of issues on it's own if you try to play it as an actual game and not a scenery painter, which is all its' really good for. It's always been ocean wide, pond deep.

It's basically an emulator versus native C code, it's completely relevant