.NET Native (a.k.a. CoreRT) is more like what you get with Go, a single native binary. You need to know the CPU architecture ahead-of-time, but it has performance advantages. You can also strip out unused code with IL Linker and do things like Profile Guided Optimisation.
Keep in mind that if you're using Docker containers then you probably want to share the framework, otherwise this will increase the size.
There's some more discussion around this in the .NET Core talks that I've given: https://unop.uk/talks/
I think this really needs to be emphasized, it's a great feature and this was the one question I had when I clicked the link, but I didn't get the answer until I came here.
This ahead of time compilation is smart for server solutions where cold start time is an issue, certain kinds of complex projects where start times become an issue, or for small devices where start times are among the biggest usability issues ever.
You're dead on -- proper "Server" solutions, like we see in architecture diagrams or on back-end tiers, are generally insensitive to startup times. As a rule they're spooled up before being connected to the larger app, or are 'the app' itself and have load balancing or operational pauses to mitigate up-time effects (where necessary).
In 2020, though, as people are working with microservices and containerized server deployments you end up with a lot of 'servers' where 'apps' used to be. Particularly for focused web apps initial startup time can be a major issue in a shared environment. That's where NGEN or AOT can come into play to happily minimize startup time and memory demands. Parallel computing and number crunching loads can also benefit if you're looking at lots of short lived servers, or a domain that challenges the compiler for whatever reason.