C# vs. VB for Office development (part 1/?)

I'm at a Tech-Ed cabana session entitled "VB.Net vs. C# for Office development with Visual Studio .NET". It's going over a few reasons why it's nicer to use VB for developing for office.

The first version that is mentioned is that many methods in office take long number of parameters (the speaker just mentioned 30), where almost all of these parameters are optional. In VB this is simple since it supports optional parameters and will substitute Type.Missing for all the optional parameters. So in excel you can do something like:

 Document d = Word.Documents.Open(fileName, ReadOnly:=True)

whereas in C# you'd have:

 Document d = Word.Documents.Open(fileName, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, true, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, 
                                 Type.Missing, Type.Missing, Type.Missing, Type.Missing);

Yuck. Really ugly in C#. My question is, "why were the office APIs designed to have methods that take 30 parameters? Why isn't there some nice structure that encapsulates all that state into something reasonable. Something like:

 OpenFileArgs args = new OpenFileReadonly(fileName);
Document d = Word.Documents.Open(args);

i.e. OpenFileArgs encapsulates all that amazing amount of state. And, for convenience I can do things like subclassing that will set up things (like readonlyness) automatically. It's much more readable and doesn't require these UBER methods that carry around so much baggage (hidden or not) with them.

I really don't like reading APIs that have these sorts of methods as I find them incredibly confusing.