What are the benefits to using a partial class as opposed to an abstract one?

Partial classes have nothing to do with object inheritance. Partial classes are just a way of splitting the source code that defines a class into separate files (this is for example done when you create a new form in your Windows Forms application - one file is "your" code, another file .designer.cs contains the code that VS2008 manages for you).

Partial classes should be restricted to using with auto-generated code, where the other code cannot be modified. Using it as a substitute for inheritance or adding functionality are not best practices.

If you have a large class, its already wrong. Code should be refactored into multiple "real" classes instead of multiple files. Large classes in general signifies the class is doing too many things and violates SRP (Single Responsibility Principle).

It sounds like your question is what the difference is between

partial class Foo
{
  PART ONE
}
partial class Foo
{
  PART TWO
}

and

astract class FooBase
{
  PART ONE
}
partial class Foo : FooBase
{
  PART TWO
}

While they may appear somewhat similar, and in some cases the latter construct could be used in place of the former, there are at least two problems with the latter style:

-1- The type FooBase would likely have to know the identity of the concrete type which was supposed to derive from it, and always use variables of that type, rather than of type FooBase. That represents an uncomfortably-close coupling between the two types.

-2- If type Foo is public, type FooBase would have to also be public. Even if all the constructors of FooBase are internal, it would be possible for outside code to define classes which derived from FooBase but not Foo; constructing instances of such classes would be difficult, but not impossible.

If it were possible for a derived type to expand the visibility of a base type, these issues wouldn't be overly problematical; one would regard FooBase as a "throwaway" identifier which would appear exactly twice: once in its declaration, and once on the declaration line for Foo, and figure that every FooBase would be a Foo in disguise. The fact that FooBase could not use Foo instance members on this without a typecast could be irksome, but could also encourage a good partitioning of code. Since it isn't possible to expand the visibility of a base type, however, the abstract-class design seems icky.