The XAML file and the "code-behind" file are typically separate, so a mechanism is needed to weave them together. If each were compiled into a separate class, then composition or inheritance could be used to combine the two. Partial classes allow the two files to be compiled together into a single class. Is this necessary? No, but it might be "better" in some ways (at the cost of adding another language feature).
If inheritance were used, then the XAML-derived class (which would presumably have to be the base class, itself inheriting from System.Windows.Forms.Form) could be inherited by several different "code-behind" classes, possibly specifying different behaviours for the same interface. This can be done with partial classes too; the main difference would be that the woven partial classes would be covariant with System.Windows.Forms.Form and not with the XAML-derived base class - they could be treated as equivalent only insofar as both were forms, and the fact that both had the same UI components would be hidden from the class hierarchy. In general, I'm not sure that the relationship between different sets of handlers for the same UI components is the kind of relationship (IS-A) that should be modelled with inheritance, so this seems to me to be a good thing.
I don't know what the case would be against composition. It would surely be simple enough to have an instance of the XAML-derived class as a private member of an "outer" class which provided event-handlers for it. The only objection I can imagine is that this would mean that you had to have twice as many classes as before - instead of having one class per form, you would need both the XAML-derived class and the "outer" class each time. Is an extra language feature worth it?
The real reason, I strongly suspect, is that weaving partial classes together is more like the way ASP.Net works, and makes XAML interface coding and web interface coding look more like each other. Don mentioned that his website is now served as XAML internally within Microsoft, where presumably it's rendered as a XAML document within the Longhorn browser/explorer. So XAML is meant to "stand alone" (within the context of a suitable browser) as well as provide a UI design markup for applications. XAML over HTTP rendered in Longhorn = the Microsoft web. Now doesn't that thought warm the heart of your cockles?