Having taken a mooch through his blog, I came across a post surrounding designing custom controls. Or at least, his opinions regarding VS's shortcomings. I thought it'd be worthwhile to go through each point in turn and analyse/debunk them:

1. Sub-classing a control doesn't cause the new control to inherit any design-time attributes, specifically Toolbox icon.
2. Altering a property in the child class causes the property value to show in bold in the property page for the control when it's placed on a form. Oh, and the fact that changing the value of a property in the class thusly doesn't propogate through to any derived application.

So, in response;

1. Why's this a bad thing? This might just be down to a matter of opinion, but surely the name, icon and other odds and ends should be down to the developer. How about if you inherit from System.Windows.Forms.Control,... what icon should be used then? Or one of the abstract base clases like S.W.F.ListControl?
   As a Control developer, get off your arse and choose an icon, rather than expecting Visual Studio to do everything for you.
2. Altering a property in a way that causes the property value to show in bold means that you've done it the wrong way. The author even goes as far as mentioning the System.ComponentModel.DefaultValueAttribute and then whines that using this is a "work around" to a "bug" in Visual Studio.
   Consider for a moment if the Visual Studio designer determined what the default property value was based on the return value for the property get routine, this routine could go off and query the Registry / contact a web service / choose the Nth font installed based on the number of elapsed seconds in this specific minute, in short - the return value could be entirely nondeterministic and even long running. By decorating the property with an Attribute, any Designer tool can determine immediately and deterministically what the default value for the property is. This also results in NO code being generated within the application using the control and thus any change to the default value being propogated upon recompilation of the Control.

I'm not taking this as an excuse to bash a Microsoft basher, don't get me wrong, Visual Studio bugs the crap out of me at times too, but someone with such a deep and broad level of experience should really at least make sure they understand what they're talking about, and more importantly, how to use the tools at their disposal, before they chuck an "it's all crap because it's not VFP/VB6" bitch-fest.

Property Attribute Example
Just to highlight why the attribute based default value for a property is better, consider the following code:

public class ControlWithProperties : Control
{
    private Font _font;

    [DefaultValue("Segoe UI")]
    public override Font Font
    {
        get { return _font; }
        set { _font = value; }
    }

    public Font OtherFont
    {
        get
        {
            if (_font == null)
            {
                if (DateTime.Now.Second < 30)
                {
                    _font = new Font("Century Gothic", 20);
                }
                else
                {
                    _font = new Font("Comic Sans MS", 20);
                }
            }
            return _font;
        }
        set
        {
            _font = value;
        }
    }
}

With the first example property, any Visual Designer (or indeed parser, decompiler, etc) can immediately determine what value to show in a property grid, but with the second (albeit contrived) example, all bets are off. For describing the attributes of something, attributes are definately the way to go.