Well, I'm not sure that's fair. In most dynamic languages, you can add type annotations and/or formal pre/post-conditions to selected pieces of code, usually for either compiler verification or optimization purposes; thus making a little piece of your code statically typed. Would you say they should just "go all the way to C#" (or ML, or whatever you prefer?) Of course not.
The C# situation with dynamic is analogous. It's for people who like working in a static language, but want a particular piece of code dynamically typed because it happens to be very convenient for the task at hand. Obviously, there are a fair number of such tasks; mostly whenever you're dealing with a piece of structured but unpredictable data that lives outside your static bubble, like XML or external unmanaged libraries.
And var isn't really worth mentioning; it's just very simplistic type inference on declarations. It's just (very good) syntax sugar and doesn't have any special semantic meaning at all.
The part I fear most is that every object suddenly becoming an ExpandoObject; there will be someone 'clever' that will do that. I'm speculating, but when you have a hammer...
I think this also has to do with language expectations, express-tivity, and maintainability. A project already using a dynamic language will have some sort method to deal with the nature that certain calls will or will not exist. The addition annotations/conditions seem like optimizations, but doesn't fundamentally change how a programmer would go about using that dynamic language. C#, on the other hand, the language is more constrained to begin with. A (C#) programmer would normally expect certain things such as an interface having a certain number of methods with certain types. Just imagine a library exposing an api with expandos... =p
I agree, and so does Microsoft, actually; I had the chance to ask a fellow on the C# team (I don't work for MS but I was there recently) why some things in the BCL weren't made dynamic -- for example, when you call a constructor via reflection, and it passes you an object whose type is indeterminate at compile-time, why doesn't it now return type dynamic instead of type object?
His answer was basically your concern, that they didn't want to get in the habit of exposing dynamic things all over the place, since they felt it was sort of an unexpected thing to be doing in a language like C#. Hopefully third-party library programmers will be equally judicious.
The C# situation with dynamic is analogous. It's for people who like working in a static language, but want a particular piece of code dynamically typed because it happens to be very convenient for the task at hand. Obviously, there are a fair number of such tasks; mostly whenever you're dealing with a piece of structured but unpredictable data that lives outside your static bubble, like XML or external unmanaged libraries.
And var isn't really worth mentioning; it's just very simplistic type inference on declarations. It's just (very good) syntax sugar and doesn't have any special semantic meaning at all.