That's actually one thing I don't understand. Having a full framework installed on the machine means all the modules will be updated the .net framework. Shipping with your own binaries means you will need to do the upgrade yourself. That's fine if you have an active team maintaining the application. But in the real world there are many many apps and websites developed once and rarely upgraded. These will not receive security patches if they shipped with their own binaries. I am not convinced this is a benefit.

Your real world is not necessarily the same as everyone else's real world, and in some cases there is great benefit in being able to say "I am going to update the app that I own, and I can guarantee that it won't affect the app that you own, because they both ship with their own binaries, not a shared, system-wide framework."

There are other cases e.g. using EC2 Vms in AWS where it's moot; machines come and go, there is only ever one app per machine. So installing per machine or per app are both 1 install, except that the per-app install has the potential to be slimmer not 1-size fits all.

In short, it's more friendly to new scenarios involving clouds and containers.

And I can see how that will be useful in the case of an active team deploying a service continuously. But I am ready to bet it will also be used (because it's the cool new technology) by lots of people who will create something, perhaps with the intention to maintain it (or not) then move on, and that's how you end up with unpatched software online and sensitive data leaked.