It's important to point out that doing this is a bad idea (as the author of the article notes.) The behavior specified by this plist value is meant for daemon processes. Google is using it because they run daemon processes for the window renderers in Chrome. The daemons need some of the Cocoa application stuff to render things like form inputs with native widgets, so they have to use some 'real' (NSApplication) Cocoa application stuff to get that that, which normally creates a dock icon for you (instead of just running a UNIX process.) This Info.plist value suppresses that behavior, along with the dock icon bounce and some other important stuff.
The author then goes on to ignore his own advice, and shows us demoing the trick in his own application.
It makes sense for the author to use it, since he wants to emulate the behaviour of the "Recent Applications", etc. Dock folders. A bounce is unwelcome in this case, and the other benefits of the normal application startup (like being registered in the "Recent Apps" list) are useless for him.
It's important to point out that doing this is a bad idea
You've explained why it's done to get Cocoa components, but you haven't pointed out why it's a bad idea. It seems faster, which is good. Does it do any harm?
Its behavior for applications which use a GUI is unspecified by Apple (afaik) which means it could break at any time. Among other problems: Dock icon weirdness (no bouncing, status changes are strange) your app won't show up in the "Recent Applications" menu, your app won't be registered correctly in the process list, and likely some other stuff I can't name off the top of my head. Don't do it. You aren't an exception.
Indeed. "Smart people" abusing undocumented behaviour of Windows releases is usually the cause of compatability problems when a newer Windows version is released. You can read a few articles on Raymond Chen's The Old New Thing to get some understandong on how far Microsoft had to go to make sure that old programs doing stupid things kept working in new Windowses.
You don't abuse undocumented features of your environment as a developer. It's always a bad idea, it will always inevitably come back and bite you (or even worse, your users) a few years later.
The author then goes on to ignore his own advice, and shows us demoing the trick in his own application.