Unity's plan to migrate from Mono to .NET CoreCLR

Pretty much this. Add in that in a relatively small project in which you include a few asset store items along with your own code the code build time might be 15s, followed by 15s to launch the editor into play mode; now they're talking about some improvements that might shave a few ms off the time, or a multi-year project (which might actually make a difference); but which probably will be implemented as poorly as everything else they've done.

In another year they'll be bored of this performance upgrade, and they'll start something else up.

On some of their other attempts: IL2CPP has performance improvements, but it also has issues such as on a select % of laptops it'll just cause a random crashes (even in a very basic project). They tried adding DOTS for graphical improvement rendering a lot of items, but then just sort of semi-abandoned it to work on other tasks.

Let's not even get started on them splitting the rendering pipelines.

Unity devs aren't on forums.

They're on Discord, Matrix, IRC.

Just like Unreal does, many seem unaware that Blueprints and the C++ dialect used by it also make use of a GC.

How does Unity coupe with pauses?

In two ways, by using a somewhat modern GC, mark and sweep is like "introduction to tracing GC" 101 CS. So pauses are somewhat minimal.

.NET also supports value types and explicit memory management, if one wants to go down that route.

Which they do, with their C# subset for high performance code named Burst.

Maybe you know Mike Acton of Data Oriented fame, he is one of the lead architects at this infrastructure.

Nowadays, they do have option to use incremental garbage collector which in theory alleviates frame spikes.

Why though? Microsoft is already working on full AOT for .NET 7