I completely disagree - are you really suggesting that use of identity columns is somehow a greater evil that not designing your database properly?? I'm not suggesting that DBAs become flawless human beings and never make mistakes but designing a new schema or table isn't something that you do hundreds of times a day.  It is something you do relatively infrequently and, because it can have large consequences down the road, should be given the appropriate time and effort to get right.  I also cannot believe that you are using the ease of defining an identity as a negative point.

Would you rather that Microsoft remove the feature and just let developers hand code a method of doing it? Of course not.

The issue described is purely about the column datatype chosen not how the value is generated.  The identity column is not the problem the datatype is. Simple as that.

I appreciate that we have to clean up after other people mistakes, god knows I've seen more than enough of them, but to suggest looking only at identity columns is ridiculous.  What if the column is an integer and it's value is calculated by doing some MAX() + 1 function (not an approach anyone would recommend yet often employed).  The issue still exists i.e. the column will run out of space to store the number and yet will never be picked up by monitoring columns which have the identity attribute defined.

This article should have concluded by recommending that DBAs simply monitor integer primary keys and the current maximum values.  That way, whatever method is used to arrive at the arbitrary value, you will still pick up on a disaster waiting to happen.