I saw this a little while ago on Hacker News: http://lucumr.pocoo.org/2013/2/13/moar-classes/

1. Has this taught me anything new and valuable? (If not, move on quickly)
My take-away was that if you're writing any kind of software that will be used by others, you should try to make it extensible in many places and not just a black box that can only be used one way. The reason is that sure, maybe 99% of cases are covered by your basic API, but in the 1% that isn't covered, you shouldn't force other developers to fork your library just to add some new functionality because there are no extension points.

The article was specifically talking about python authors' trend of using mainly methods and avoiding classes when not absolutly necessary, and the result of this is that it's difficult to extend behaviour. I think that the wish for simple extensibility is applicable to c# too, and any other language.

2. How can I apply insights from this article today? (Wait and I’ll forget)
I need to be mindful of where I might want to modify default behaviour and make it possible. Even if you're not writing an API - if you're on any kind of a team you should not make code so closed that to change part of it would require a big refactor. I think this also ties into general good coding practice and the SOLID principles.

3. When have I applied the ideas from this post? Where have I not, but could have? (What was the difference?)
I haven't written any public libraries, but some of the stuff I've done at mammoth maybe could use easier extension points. I think I generally do a reasonable job, I just need to keep an eye on it. I would argue that you also shouldn't go overboard and make the code harder to use for no reason.