Having used default parameters in a medium sized team on a large codebase for quite a while now (basically since day 1), I can assure you that the default argument argument feature is a wolf in sheeps clothing.
They seem sort-of handy and thus get used when you just need to toggle this small thing. However, that encourages methods to do more than one thing; or to work subtly different in different scenarios. The reliability of your codebase suffers. Furthermore, they break programming 101: encapsulation. You can't encapsulate a function with a default parameter. If you wrap that call in something else and need to pass along the default parameter, you need to add the default argument to that second function now too. If the default changes... oh boy. In essence, they encourage misdesign by allowing API's with terrible method signatures and then making it cumbersome to abstract those APIs - so you're being hurt on both ends.
Another small problem is that they're entirely static. I find the binary compatibility argument to be largely irrelevant (seriously, what tiny percentage of your API is outward facing anyhow, and how many people even have customers that buy libraries but don't recompile dependencies?). A much more serious problem is that they thus encourage placeholder values (null, -1, etc) that mean something entirely different. This makes reasoning about functions much harder (irregularities are bad), and can cause surprising bugs when you manage to accidentally pass one of those placeholders. Secondly, they somewhat undermine an actually useful part of C#, namely expression-tree lambdas, which don't support this feature (so APIs with default paramaters tend to be unworkable in expression trees).
I wish they'd never released the feature, or at least made it very annoying to write APIs for so that its usage would be limited to there where absolutely necessary (e.g. interop with APIs designed with it in mind).