The same reasons that Python, Ruby, and Node are almost always reverse-proxied by a "bigger" web server. The "closer to the metal" server handles things like virtual hosts, load balancing, black lists/white lists, throttling, speaking to the kernel-layer about low level IP port specifics, while the "closer to the language" server deals with the realities of your business logic and application code.
That separation of concerns between two web servers in a reverse-proxy has become a very useful mainstay "Production best practice" in the Linux/Unix world, so it's nice to see Kestrel follow the larger trends there. It makes it easier to use Kestrel in most Linux/Unix deployments, but some of the reasons that it became best practice apply back to Windows. For instance, the principal of least privilege applies in that the application web server can run in a much more isolated process space than the kernel-level web server and the service boundary to secure between them in a reverse-proxy scenario is "just HTTP".
As for performance, IIS is a rather good reverse proxy and efforts to make it better for Kestrel have benefited Node, Python, and Ruby hosting on Windows, as well as vice versa.